Re: initial extent is LESS THAN first extent size :WHY??

Sujata, 1. no. An extent can not span a chunk. Yes you are right any table over 2 gb will have multiple extents. I usually fragment the table in this case so you benefit from this Informix limitation. 2. no. Each initial extent is allocated before the load is started at table creation time (however the pages are not formatted merely reserved for use). 3. The indexes are created in the same table space with the table (this means you need enough space for indexes and data) unless you create the indexes in another dbspace (use the "in" clause during create index). 4. sysmaster database. Regards David Ashby ______________________________ Reply Separator _________________________________ Subject: initial extent is LESS THAN first extent size :WHY?? Author: <ssoman@omm.com> at WCA-INET Date: 29/4/98 5:14 PM Hi all, I had a table with 32 extents ( about 5GB in total size ), I re-organized this table by creating a copy of it in a seperate new dbspace with the first extent size calculated to be 10% more than the current size, and the next extent being 20% more for growth. I ran an "insert into newtab select * from oldtab", and guess what, I end up with 2 extents, not one as I expected. Each extent is in a different chunk. ( the first one filled up an entire chunk ) and the next one a part of the next I have a few questions on this scenario 1. Can I have ONE extent spanning over multiple chunks, or does multiple chunks mean multiple extents ( assuming there is nothing but that table on those specified chunk(s) ) If the latter is true, does that mean that any table > 2GB CAN NEVER have only ONE extent. 2. I re-organized two tables in the same method, and ran the "insert into..." parallelly. Would this interfere with space allocation, or does INFORMIX pre-allocate space, and when ? 3. When I create the indexes on this table ( which takes up more than 2.5 times the data space ), will that be treated the same way as the data pages ? 4. How do I find out where the indexes of a table are located ( physical disk/chunk ) As usual, thanks for your responses Sujata ***************************************** Sujata Soman E-Mail: ssoman@omm.com O'Melveny & Myers, Los Angeles ******************************************