Jeff Davis <[EMAIL PROTECTED]> writes: > On Sun, 2008-11-23 at 14:05 -0500, Tom Lane wrote: >> A possible problem is that if a relation is filled all in one shot, >> autovacuum would trigger a single vacuum cycle on it and then never have >> a reason to trigger another; leading to the bits never getting set (or >> at least not till an antiwraparound vacuum occurs).
> This would only be an issue if using the visibility map for things other > than partial vacuum (e.g. index-only scan), right? If we never do > another VACUUM, we don't need partial vacuum. Well, the patch already uses the page header bits for optimization of seqscans, and could probably make good use of them for bitmap scans too. It'd be nice if the page header bits got set even if the map bits didn't. 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. 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. 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