Heikki Linnakangas <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
