On Thu, Dec 6, 2012 at 1:01 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I think taking a second whack at setting the visibility bit is a fine > idea, but let's drop all the rest of this premature optimization.
+1. If there's any optimization needed here, we should try to do it by remembering relevant details from the first vacuum pass in backend-private memory, rather than by changing the on-disk format. One other thought: I'm wondering if we shouldn't try to push the work of setting the all-visible bit into heap_page_prune(). That would allow HOT pruning to set the bit. For example, consider an all-visible page. A tuple is HOT-updated and the page becomes not-all-visible. Now the page is pruned, removing the old tuple and changing the line pointer to a redirect. Presto, page is all-visible again. Also, it seems to me that heap_page_prune() is already figuring out most of the stuff we need to know in order to decide whether to set PD_ALL_VISIBLE. The logic looks quite different from what is happening in the vacuum code, because the vacuum code iterates over all of the line pointers while the pruning code is walking HOT chains. But it seems to me that a page can't be all-visible unless there are no dead line pointers and no HOT chains of length != 1, and heap_prune_chain() does manage to call HeapTupleSatisfiesVacuum() for every tuple, so the raw information seems like it is available without any additional CLOG lookups. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
