Re: Set visibility map bit after HOT prune

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Set visibility map bit after HOT prune
Дата
Msg-id CA+U5nMKOH2u=GuwJwEp97B6vLyK7-30g_1eYTU8E=j+FHAU10A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Set visibility map bit after HOT prune  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Set visibility map bit after HOT prune
Список pgsql-hackers
On 20 December 2012 00:43, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Dec 19, 2012 at 12:39 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> The benefit of saying that only UPDATEs clean the block is that this
>> penalises only the workload making the mess, rather than everybody
>> cleaning up repeatedly over one messy guy.
>
> Right, but there are plenty of situations where having everybody clean
> up after the messy guy is better than waiting around and hoping that
> Mom (aka vacuum) will do it.

The problems I see are that cleaning on SELECT is too frequent,
interferes with foreground performance and re-dirties data blocks too
often.

Waiting for Mom is configurable, since we can set parameters for
autovacuum. But we can't turn off the cleaning by SELECTs, which makes
the configurability of autovacuum somewhat moot.

We could also contact the Cleaner instead.

ISTM that if someone spots a block that could use cleanup, they mark
the block as BM_PIN_COUNT_WAITER, but don't set pid. Then when they
unpin the block they send a signal/queue work for a special cleaning
process to come in and do the work now that nobody is waiting. Logic
would allow VACUUMs to go past that by setting the pid. If we
prioritised cleanup onto blocks that are already dirty we would
minimise I/O.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Review of Row Level Security
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1