Re: Dirty pages in freelist cause WAL stuck - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Dirty pages in freelist cause WAL stuck
Date
Msg-id 9336.1166458386@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dirty pages in freelist cause WAL stuck  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Dirty pages in freelist cause WAL stuck  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:
> I think what you are saying is: VACUUM places blocks so that they are
> immediately reused. This stops shared_buffers from being polluted by
> vacuumed-blocks, but it also means that almost every write becomes a
> backend dirty write when VACUUM is working, bgwriter or not. That also
> means that we flush WAL more often than we otherwise would.

Do we care?  As long as the writes are done by the vacuum process, ISTM
this is taking load off the foreground query processes, by saving them
from having to do writes.

In any case, I'm unclear on why we should add a boatload of complexity
to improve performance of something that's done as rarely as VACUUM
FREEZE is.  Quite aside from maintainability concerns, even a few extra
cycles added to the more common code paths would make it a net
performance loss overall.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Question about debugging bootstrapping and catalog entries
Next
From: Bruce Momjian
Date:
Subject: Re: pg_restore fails with a custom backup file