RE: max pages allocated issue

Posted in 2009

Summary

Floyd Wellershaus said Informix support told him the roughly 16.7 million page limit applies to data pages only, so removing indexes would not help, and to monitor actual Data Pages from oncheck -pt. Neil Truby disputed this: for in-table indexes the limit covers data and indexes. Fernando Nunes warned that dropping an in-table index takes time; Madison Pruet noted in-table indexes hurt HDR performance.

Auto-generated by Claude from the posts below — may be imperfect; read the full thread.

Topics: General Discussion

Floyd Wellershaus — Wed, 1 Jul 2009 18:02:10 -0500 (CDT) — source: Usenet: comp.databases.informix

Thanks. The answer however is that removing the indexes won't help. According to Informix support, who I called to make sure, the 16,775 million page limit is against data pages only. I was also using the wrong value from the oncheck -pt. To monitor, use the actual number of Data Pages, not the Data Pages allocated. ----- Original Message ----- From: "Ian Michael Gumby" >;im_gumby@hotmail.com

↪ replying to Floyd Wellershaus

Neil Truby — Thu, 2 Jul 2009 08:28:08 +0100 — source: Usenet: comp.databases.informix

>> "Floyd Wellershaus" <floyd@fwellers.com> wrote in message >> news:mailman.110.1246489338.4791.informix-list@iiug.org... Thanks. The answer however is that removing the indexes won't help. According to Informix support, who I called to make sure, the 16,775 million page limit is against data pages only. I was also using the wrong value from the oncheck -pt. >> To monitor, use the actual number of Data Pages, not the Data Pages >> allocated. That's bollocks. If the indexes are "in table", as you said in the OP, the 16g limit applies to the data and indexes.

↪ replying to Neil Truby

Fernando Nunes — Thu, 02 Jul 2009 22:52:51 +0100 — source: Usenet: comp.databases.informix

Neil Truby wrote: >>> "Floyd Wellershaus" <floyd@fwellers.com> wrote in message >>> news:mailman.110.1246489338.4791.informix-list@iiug.org... > Thanks. > The answer however is that removing the indexes won't help. According to > Informix support, who I called to make sure, the 16,775 million page > limit is against data pages only. > I was also using the wrong value from the oncheck -pt. >>> To monitor, use the actual number of Data Pages, not the Data Pages >>> allocated. > > That's bollocks. If the indexes are "in table", as you said in the OP, > the 16g limit applies to the data and indexes. > Droping an index "in table" of such a big table will take time. Be aware of that. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

↪ replying to Fernando Nunes

Madison Pruet — Thu, 02 Jul 2009 22:18:09 GMT — source: Usenet: comp.databases.informix

Fernando Nunes wrote: > Neil Truby wrote: >>>> "Floyd Wellershaus" <floyd@fwellers.com> wrote in message >>>> news:mailman.110.1246489338.4791.informix-list@iiug.org... >> Thanks. >> The answer however is that removing the indexes won't help. According >> to Informix support, who I called to make sure, the 16,775 million >> page limit is against data pages only. >> I was also using the wrong value from the oncheck -pt. >>>> To monitor, use the actual number of Data Pages, not the Data Pages >>>> allocated. >> >> That's bollocks. If the indexes are "in table", as you said in the >> OP, the 16g limit applies to the data and indexes. >> > > Droping an index "in table" of such a big table will take time. > Be aware of that. Also, keeping the index in the same partitions as the data will impact HDR performance because the BTREE log records will have to be processed by the same recovery thread as the data log records. > >