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
