Jim C. Nasby wrote: > > > Perhaps my point got lost... in the case where no index keys change > > > during an update, SITC seems superior in every way to my proposal. My > > > idea (let's call it Index Tuple Page Consolidation, ITPC) would be > > > beneficial to UPDATEs that modify one or more index keys but still put > > > the tuple on the same page. Where SITC would be most useful for tables > > > that have a very heavy update rate and very few indexes, ITPC would > > > benefit tables that have more indexes on them; where presumably it's > > > much more likely for UPDATEs to change at least one index key (which > > > means SITC goes out the window, if I understand it correctly). If I'm > > > missing something and SITC can in fact deal with some index keys > > > changing during an UPDATE, then I see no reason for ITPC. > > > > I understood what you had said. The question is whether we want to get > > that complex with this feature, and if there are enough use cases > > (UPDATE with index keys changing) to warrant it. > > Ideas on how to test a table to see how many tuples would fit this > criteria? > > Or we could just shelve ITPC as a possibility in the future, after we > see how much the limitations of SITC hurt.
Probably. I am not sure even SITC is a win given the complexity it will add, but I think it is worth trying. Getting into more complex cases where chains change indexed values seems like something we could try later if we have to. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings