Re: Behavior change in PostgreSQL 14Beta3 or bug?

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Behavior change in PostgreSQL 14Beta3 or bug?
Дата
Msg-id CAH2-WzmW=v7Zmfdb2B+i8JP7Kd+CDzqzWNZwpZTk_HkSPqkPjA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Behavior change in PostgreSQL 14Beta3 or bug?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Mon, Sep 6, 2021 at 8:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Assuming that that choice was made appropriately, I think the advice you
> propose here will just cause people to waste lots of cycles on VACUUM
> runs that have only marginal effects.

Right. The advice that they should receive (if any) is to tune
autovacuum aggressively, and enable autovacuum log output. The log
output reports on whether or not the implementation applied the
optimization in each case.

As I pointed out to Laurenz just now, users that care about index-only
scans are actually the big beneficiaries here. Now they can set
autovacuum_vacuum_insert_threshold very aggressively, without doing a
useless round of index vacuuming just because one inserting
transaction out of a million aborted. Once indexes are removed from
the equation (to the extent that that makes sense), each round of
vacuuming by autovacuum only needs to do work that is proportional to
the number of unset-in-vm heap pages.

I believe that that trade-off makes a lot of sense. Autovacuum has
little chance of keeping anything like 100% of all pages set in the VM
anyway. But it can get a lot closer to it in some cases now.

-- 
Peter Geoghegan



В списке pgsql-general по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Behavior change in PostgreSQL 14Beta3 or bug?
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Behavior change in PostgreSQL 14Beta3 or bug?