Tom Lane wrote:
Reflecting on it though, maybe Heikki described the behavior too pessimistically anyway. If a page contains no dead tuples, it should get its bits set on first visit anyhow, no? So for the ordinary bulk load scenario where there are no failed insertions, the first vacuum pass should set all the bits ... at least, if enough time has passed for RecentXmin to be past the inserting transaction.
Right. I did say "... after a delete or update, it takes two vacuums until ..." in my mail.
However, my comment above was too optimistic, because in an insert-only scenario autovac would in fact not trigger VACUUM at all, only ANALYZE. 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.
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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
