On Mon, Dec 21, 2009 at 12:56 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Simon Riggs wrote:
>> I notice that during copy_heap_data() we make no attempt to skip pages
>> that are all visible according to the visibilitymap. It seems like it
>> would be a substantial win to copy whole blocks if all the
>> pre-conditions are met (I see what they are). I'm surprised to see that
>> neither CLUSTER nor VACUUM FULL made use of this previously. I think we
>> either need to implement that or document that vacuum will not skip
>> all-visible pages when running VACUUM FULL.
>
> Unfortunately the visibility map isn't completely crash-safe at the
> moment (see comments in visibilitymap.c for details). So it's not safe
> to use it for such purposes. I was planning to address that in 8.5 but
> it seems I won't have the time.
Well since we're going to have to read in the page to do the copy we
could just use the page header flag PD_ALL_VISIBLE instead.
But sequential scans already use that bit and I'm assuming but haven't
checked that these access paths do use the same underlying access path
as sequential scans. In which case it won't really save much since the
main advantage would be skipping the visibility checks. Saving the
actual work to copy tuples retail instead of the whole block wholesale
seems unlikely to buy much and would result in us not compacting space
on the page and storing accurate free space map values which I think
people would expect from both of these commands.
If I'm wrong and these commands are not using a sequential scan under
the hood or the fact that they're using SNAPSHOT_ANY defeats that
optimization then perhaps there is something there. On the third hand
presumably all the hint bits will be set if the page bit is set so
perhaps there's nothing there even so.
--
greg
