Re: 5.5m to select 590 rows from 1 table

We have a much smaller HP machine with volume manager. A table with up to 1000 rows takes about 3 seconds to read and order by a non-indexed field. How big are your rows? The extent specification may be your problem, but I find that to be suspicious. You should try creating another table, maybe a temporary one, for testing. In other words, duplicate the table (using a smaller extent size) and see what happens when you select from it. If it works better then drop the original and rename that table to replace the original (if there are references to the table, then you must recreate them also). costrom@solair1.inter.NL.net (Craig Ostrom) wrote: >Config: > >Informix engine: Online V5 >Hardware: HP-9000 T500 (1GB RAM, 3 Processors) >O/S: HP-UX 9.04 > >We have a bit of a problem with one of our tables. The table only has >590 rows in it, yet it takes 5.5 minutes to do a straight select *. > >We know that the table extents have not been sized correctly and we are >going to re-organise the database soon, but is it just fragmentation? > >A problem that we know about is that we only have one dbspace. > >The more complex issue is that the root chunk resides on a central stripe >over 12 disks, the remainder of each of the disks is used for raw image >space (not Informix blobspace). This is all handled by the HP volume >group/logical volume manager. > >The big question is, could the problem be due to extent fragmentation or >is it more likely to be something else like disk head contention? > >If you think it is something else, could you say what, please. > >Our DBA has told us that the HP Volume Manager works well with Informix, >is this the case. Sorry, I know we have posted a message about this before. > >Thanks in advance for your time. >