"Madison Pruet" <mpruet (AT) comcast (DOT) net> wrote

OK...

1. Ability to be able to change the owner of anything.
2. Ability to be able to rename anything.

Surely these are fairly simple?

Harder ones...

1. If have have a down chunk the ability to be able to restore just that
chunk and the rollforward
logs on just that chunk. ala Oracle recover datafile

2. Transportable table..I mean dbspaces...ala Oracle

3. That onmode -B to flush stuff to disk (useful to reduce checkpoint
times) to be
documented and supported

4. Fix that bug listing in PTS where oncheck does not check everything it
could
i.e. a better oncheck.

Also.

1. truncate table x should drop all extents.

2. create table..with no first extent size specified should not allocate an
extent
(why waste space if the table is not used by this particular customer
e.g. SAP/Baan
etc with 40,000 tables!!)

3. Ability to alter the first extent size on a table then

a) a table with no extents would use this as the first extent size
i.e. unused table but the customer decides they want to use a new
area of the overall
application suite which now needs this table to have 100,000 rows
loaded.
Hassle if constraints/views etc also used.

b) alter fragment on table x init in .. could use the new extent size

Wild stuff.

1. We have (my syntax is crap but you get the idea)
create index myind on a (b) fragment with b=null in dbspace_1,
remainder in dbspace_2

why need the remainder?

create index myind as select a from b where a is not null.

e.g. table use to sent an interface file to another system

create table mytab (col1 char(20), col2 int,....,batchid integer)

batchid=null until the data is write to a file to be sent to the
receiving system
(e.g. invoice file)...

Rows gradually get put in the table, once per hour a process does

a) select * from table where batchid is null
b) sends this data out to the other system
c) updates these rows to have a given batchid.

create myind index1 as select * from mytab where batchid is null

would be a much smaller index, probably with less levels!

And a simple one...when message INFORMIXSERVER not found in sqlhosts file
or DBSERVERNAME not found in sqlhosts file could the message include the
name
it is looking for? This would make it much easier to debug!

Also oninit -v option to be documented.

All of onstat options to be documented.

More monitoring stuff added to sysmaster (add everything onstat does and
document the
correspondence)...at least as much as you can.

I'm off to sleep now!

Hi, Madison,

It would be nice to see the following two features in IDS9.6:

1. Ability to manage FIRST/NEXT extent size for index.
Extent size is a very big problem for big tables, containing
LVARCHAR. For such tables, index extent size, calculated
by Informix automatically, becomes too small, and the table
might easily run out of extents for the index partition
while it has just few extents in the data partition

2. Ability to PURGE all data from a table in a single
unlogged operation.
Current workaround is to drop the table and create it again,
which is sometimes not possible.
PURGE should be considered DDL, not DML statement,
and should be non-recoverable.
PURGE should also release all unused table extents except
the initial extent.

Best regards,
Alexey Sonkin


-----Original Message-----
From: Madison Pruet [mailto:mpruet (AT) comcast (DOT) net]
Sent: Friday, February 06, 2004 6:41 PM
To: informix-list (AT) iiug (DOT) org
Subject: Whatcha' wanta have?????


As a mild diversion from the IDS-DB2 conversion thread, its time for one of
my more favorite exercises. ;-)

We are nearing the end of the coding cycle for IDS 9.5. We've got a whole
bunch of really cool stuff in place and - well - its time to get input from
you guys as to what you want to see in the 9.6 release.

Now, I know that everyone's favorite thing is going to be "marketing", but
I'm in development. So I need to talk features and functionality. So feel
free to send them on in.

Just an FYI - I'll be away for a while and won't be able to get email via my
comcast email address. But, I'll be following the newsgroup rather closely.

Also, next week I'll be in some planning meeting. So getting responses back
fairly quickly would really help.

Thanks

M.Pruet

sending to informix-list

Hi, Madison,

It would be nice to see the following two features in IDS9.6:

1. Ability to manage FIRST/NEXT extent size for index.
Extent size is a very big problem for big tables, containing
LVARCHAR. For such tables, index extent size, calculated
by Informix automatically, becomes too small, and the table
might easily run out of extents for the index partition
while it has just few extents in the data partition

2. Ability to PURGE all data from a table in a single
unlogged operation.
Current workaround is to drop the table and create it again,
which is sometimes not possible.
PURGE should be considered DDL, not DML statement,
and should be non-recoverable.
PURGE should also release all unused table extents except
the initial extent.

Best regards,
Alexey Sonkin


-----Original Message-----
From: Madison Pruet [mailto:mpruet (AT) comcast (DOT) net]
Sent: Friday, February 06, 2004 6:41 PM
To: informix-list (AT) iiug (DOT) org
Subject: Whatcha' wanta have?????


As a mild diversion from the IDS-DB2 conversion thread, its time for one of
my more favorite exercises. ;-)

We are nearing the end of the coding cycle for IDS 9.5. We've got a whole
bunch of really cool stuff in place and - well - its time to get input from
you guys as to what you want to see in the 9.6 release.

Now, I know that everyone's favorite thing is going to be "marketing", but
I'm in development. So I need to talk features and functionality. So feel
free to send them on in.

Just an FYI - I'll be away for a while and won't be able to get email via my
comcast email address. But, I'll be following the newsgroup rather closely.

Also, next week I'll be in some planning meeting. So getting responses back
fairly quickly would really help.

Thanks

M.Pruet

sending to informix-list


sending to informix-list

Alexey Sonkin wrote:
A well known request - not unreasonable.

PURGE TABLE - aka TRUNCATE TABLE...

Reasonable request - mostly. I agree it is probably DDL rather than
DML - it certainly isn't a regular DELETE operation, and should use a
different privilege, and ALTER TABLE might be OK, though a new
specific TRUNCATE privilege would be better, I think.

I know Oracle doesn't allow recovery of its TRUNCATE TABLE, but then
it doesn't allow any other DDL operation to be recovered from.

However, Informix does provide recovery of every operation within a
transaction -- why would you want to lose the ability in this one
statemen? You can drop a table in a transaction and rollback the TX
and the table is still there - why should TRUNCATE TABLE, which does
less work, be any different?

[Background: we had an intense discussion about this, and DB2 in
particular does not want to implement a recoverable TRUNCATE TABLE.
The XPS implementation of TRUNCATE TABLE does not allow recovery.
However, it seems to me inherently bad to make one statement different
from all the rest. In particular, the XPS design is such that you
can't do anything else with the truncated table in the same
transaction. I would foresee that there would be occasions where I
wanted to delete, say, 80% of the records, but to reseed the table
with the remaining 20% of the records - in the same TX. I'd expect to
do that by unloading to a temp table (cross-loading?) the stuff to
retain, truncating the main table, and then cross-loading the material
from the temp table back into the main table, all in a single
transaction. Basically, I lost this argument - and I'm still being a
sore loser about it, because I think it is fundamentally b******t that
we can recover from dropping a table and not from truncating it.
However, here's an external contrary view, so I'm seeking to know why
it is not critical to recover from a truncated table, even though you
can recover from a dropped table.]

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler (AT) earthlink (DOT) net, jleffler (AT) us (DOT) ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Check in onmonitor and other utilities for adding chunks, dbspaces etc ,
which makes sure that user does not accidentally overwrites existing space.

that is , it should check for overlapping atleast in the same instance.


Rgds
Preetinder

Madison Pruet wrote:

sending to informix-list

Check in onmonitor and other utilities for adding chunks, dbspaces etc ,
which makes sure that user does not accidentally overwrites existing space.

that is , it should check for overlapping atleast in the same instance.


Rgds
Preetinder

Madison Pruet wrote:

sending to informix-list


sending to informix-list

Jonathan Leffler wrote:
I agree with your point of view that IDS has established practice where
everything is logged. I also agree that some operations probably should not
be logged, or only optionally.

If you introduce a a few baroque options like

truncate table with no log;
drop table with no log;
drop index with no log;

and so on, then everyone's a winner?

When indexes, constraints, etc are disabled, still there are some operations
that cannot be performed. For example, if you want to change a table to raw
state, you must drop the constraints, not just disable them. It's a flipping
nuisance.

Since a disabled constraint or index is going to be rebuilt anyway, why not
treat it as "gone" for the purposes mentioned above?

On the subject of raw tables, you cannot change their schema. Catch 22 when
you are trying dirty tricks to quickly administer large tables. We all know
we need to take a real level zero afterwards...

Similar vein: under ER, changes of schema, disabling constraints and a few
other oddities are blocked or cause administration problems. Changing a
table quickly without having to resyncronize is a hassle. Can't a change of
schema be accommodated? If the "select *" in the replicants was treated as
an expanded list of columns, then adding a column at either end shouldn't
have any effect on the replication. I suppose there are housekeeping issues.
Are there any scientific reasons against allowing this?

Let us add a column at one end, change it later at the other end, and we'll
worry about sync if the column needs it. When it doesn't, the process should
be a lot lighter than it currently is.

oooooh yeah - here's a must-have admin facility: add a new state that is not
online, not quiescent, but which will allow SPECIFIC users to connect and do
work. The list could be just informix by default, or a short list of users
defined elsewhere. On some sites, if you bring the engine online to do some
SQL admin, the bloody over-enthusiastic users will connect and make a mess
of your administration.

Related: the ability to bring up or shutdown connectors - eg we could also
control administration by making all users connect via a tcp or ipc
connector. Only administrators get local connectivity with shm connectors.
Therefore, if we can dynamically shutdown the tcp and ipc connectors
(gracefully or immediately) then we have another alternative to
administration. If ER is used on the site, then perhaps ER connections could
be allowed to stay running. This implies that the connectors are still
listening, but they are refusing connections to most attempts.