The To Do wiki says not to add things to the page with discussing here. So here are some things to discuss. Assuming the discussion is a brief yup or nope, it seems to make sense to lump them into one email:
Vacuuming a table with a large GIN index is painfully slow, because the index is vacuumed in logical order not physical order. Is making a vacuum in physical order a to-do? Does this belong to vacuuming, or to GIN indexing? Looking at the complexity of how this was done for btree index, I would say this is far from easy. I wonder if there is an easier way that is still good enough, for example every time you split a page, check to see if a vacuum is in the index, and if so only move tuples physically rightward. If the table is so active that there is essentially always a vacuum in the index, this could lead to bloat. But if the table is that large and active, under the current non-physical order the vacuum would likely take approximately forever to finish and so the bloat would be just as bad under that existing system. "Speed up COUNT(*)" is marked as done. While index-only-scans should speed this up in certain cases, it is nothing compared to the speed up that could be obtained by "use a fixed row count and a +/- count to follow MVCC visibility rules", and that speed-up is the one people used to MyISAM are expecting. We might not want to actually implement the fixed row count +/- MVCC count idea, but we probably shouldn't mark the whole thing as done because just one approach to it was implemented. sort_support was implemented for plain tuple sorting only, To Do is extend to index-creation sorts (item 2 from message <1698.1323222...@sss.pgh.pa.us>) Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
