On Tue, Feb 11, 2014 at 10:56 AM, Bruce Momjian <bruce@momjian.us> wrote:
> Right now, as I remember, only vacuum sets the visibility bits. If we
> don't want to make vacuum trigger for insert-only workloads, can we set
> pages all-visible more often?
>
> Is there a reason that a sequential scan, which does do page pruning,
> doesn't set the visibility bits too? Or does it? Can an non-index-only
> index scan that finds the heap tuple all-visible and the page not
> all-visible check the other items on the page to see if the page can be
> marked all-visible? Does analyze set pages all-visible?
A sequential scan will set hint bits and will prune the page, but
pruning the page doesn't ever mark it all-visible; that logic is
entirely in vacuum. If that could be made cheap enough to be
negligible, it might well be worth doing in heap_page_prune(). I
think there might be a way to do that, but it's a bit tricky because
the pruning logic iterates over the page in a somewhat complex way,
not just a straightforward scan of all the item pointers the way the
existing logic doesn't. It would be pretty cool if we could just use
a bit out of the heap-prune xlog record to indicate whether the
all-visible bit should be set; then we'd gain the benefit of marking
things all-visible much more often without needing vacuum.
That doesn't help insert-only tables much, though, because those won't
require pruning. We set hint bits (which dirties the page) but
currently don't write WAL. We'd have to change that to set the
all-visible bit when scanning such a table, and that would be
expensive. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
