Re: Detached indices in 7.3

David Williams wrote: . . . snip . . . > > > >I saw that right after we installed it on our test system. Yes, they > >need to change the dictionary tool, but they don't see the need to do > >so; that's one reason why I do all of my maintenance in Informix. It's > Nope! If the index and data are in separate dbspaces they can be > read in parallel. Informix does read-ahead remember? > Got it. > With PDQPRIORITY >1 Informix generate 1 scan thread per fragment > i.e. part of table or index in a dbspace. Hence 1 scan thread for > index and 1 scan thread for data since they are in seperate > 'fragments'. Have the problems with PDQPRIORITY > 0 been cleared up? That's one of the reasons why we have only implemented table fragmentation here, not PDQ. But multiply 400 tables by 'x' number of indices; it could get messy out there. My understanding of detached indices is that it is a good thing when the need exists. Should you detach them all? > > even when it is in the same dbspace, I imagine that Informix would > generate a second scan thread for the index...??? > > Oh great! Well that decreases performance as well. The cluster index > would order data pages such that the most common queries access > contingous pages and hence do not need to do any many disk seeks. > Might be something to consider . . . The tables in question are basically static. > Put those cluster commands back in again and rebuild all your indexes. See above. John Carlson Informix DBA WH Smith, Inc.