On 2013-05-13 13:21:54 -0400, Robert Haas wrote: > On Sun, May 12, 2013 at 8:50 AM, Andres Freund <and...@2ndquadrant.com> wrote: > > [ a response that I entirely agree with ] > > +1 to all that.
> It's maybe worth noting that it's probably fairly uncommon for vacuum > to read a page and not dirty it, because if the page is all-visible, > we won't read it. But only if 50(?)+ pages are marked all-visible in one go, otherwise we afair won't skip afair. And we don't skip them at all during full table vacuums. > And if it's not all-visible, and there's nothing > else interesting to do with it, we'll probably make it all-visible, > which will dirty it. It can happen, if for example we vacuum a page > with no dead tuples while the inserting transaction is still running, > or committed but not yet all-visible. Of course, in those cases we > won't be able to freeze, either. IIRC the actual values below which we freeze are always computed relative to GetOldestXmin() (and have to, otherwise rows will suddently appear visible). In many, many environment thats lagging behind quite a bit. Longrunning user transactions, pg_dump, hot_standby_feedback, vacuum_defer_cleanup_age... Also, even if the *whole* page isn't all visible because e.g. there just was another row inserted we still freeze individual rows. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
