phb07@xxxxxxxxxxxx wrote: > Hi Jeff, >> If you can help (either benchmark work or C coding), try reviving the >> features by testing them and merging them with the current tree. > OK, that's the rule of the game in such a community. > I am not a good C writer, but I will see what I could do. The FSM rewrite in 8.4 opened up more options for implementing this. The patch used to check the index for the block the nearest key is stored in, read that page in, and insert there if there's enough free space on it. with the new FSM, you can check how much space there is on that particular page before fetching it. And if it's full, the new FSM data structure can be searched for a page with enough free space as close as possible to the old page, although there's no interface to do that yet. A completely different line of attack would be to write a daemon that concurrently moves tuples in order to keep the table clustered. It would interfere with UPDATEs and DELETEs, and ctids of the tuples would change, but for many use cases it would be just fine. We discussed a utility like that as a replacement for VACUUM FULL on hackers a while ago, see thread "Feedback on getting rid of VACUUM FULL". A similar approach would work here, the logic for deciding which tuples to move and where would just be different. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
