Re: Dirty pages in freelist cause WAL stuck

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Dirty pages in freelist cause WAL stuck
Дата
Msg-id 9336.1166458386@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Dirty pages in freelist cause WAL stuck  ("Simon Riggs" <simon@2ndquadrant.com>)
Ответы Re: Dirty pages in freelist cause WAL stuck  ("Simon Riggs" <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Question about debugging bootstrapping and catalog entries
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_restore fails with a custom backup file