On 2013-05-24 11:29:10 -0400, Robert Haas wrote:
> > But even if that means needing a full page write via the usual mechanism
> > for all visible if any hint bits needed to be set we are still out far
> > ahead of the current state imo.
> > * cleanup would quite possibly do an FPI shortly after in vacuum
> > anyway. If we do it for all visible, it possibly does not need to be
> > done for it.
> > * freezing would FPI almost guaranteedly since we do it so much
> > later.
> > * Not having to rescan the whole heap will be a bigger cost saving...
>
> The basic problem is that if the data is going to be removed before it
> would have gotten frozen, then the extra FPIs are just overhead. In
> effect, we're just deciding to freeze a lot sooner.
Well, freezing without removing information for debugging.
> And while that
> might well be beneficial in some use cases (e.g. the data's already in
> cache) it might also not be so beneficial (the table is larger than
> cache and would have been dropped before freezing kicked in).
Not sure how caching comes into play here? At this point we know the
page to be in cache already since vacuum is looking at it anyway?
I think it's not really comparable since in those situations we a)
already do an XLogInsert(). b) already dirty the page. so the only
change is that we possibly write an additionall full page image. If
there is actually near future DML write activity that would make the
all-visible superflous that would have to FPI likely anyway.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services