Re: Visibility map, partial vacuums

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Tom Lane wrote:
>> So it seems like we do indeed want to rejigger autovac's rules a bit
>> to account for the possibility of wanting to apply vacuum to get
>> visibility bits set.

> I'm not too excited about triggering an extra vacuum. As Matthew pointed 
> out, the point of this patch is to reduce the number of vacuums 
> required, not increase it. If you're not going to vacuum a table, you 
> don't care if the bits in the visibility map are set or not.

But it's already the case that the bits provide a performance increase
to other things besides vacuum.

> We could set the PD_ALL_VISIBLE flag more aggressively, outside VACUUMs, 
> if we want to make the seqscan optimization more effective. For example, 
> a seqscan could set the flag too, if it sees that all the tuples were 
> visible, and had the XMIN_COMMITTED and XMAX_INVALID hint bits set.

I was wondering whether we could teach heap_page_prune to set the flag
without adding any extra tuple visibility checks.  A seqscan per se
shouldn't be doing this because it doesn't normally call
HeapTupleSatifiesVacuum.
        regards, tom lane