Re: Slow standby snapshot

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Slow standby snapshot
Дата
Msg-id CANbhV-FL4wjeb2AjEdSUf5J3QToWpoSnm4rLQhffCzL6P9z4-Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slow standby snapshot  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Slow standby snapshot  (Michail Nikolaev <michail.nikolaev@gmail.com>)
Список pgsql-hackers
On Tue, 22 Nov 2022 at 16:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Simon Riggs <simon.riggs@enterprisedb.com> writes:
> > On Tue, 22 Nov 2022 at 16:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> If we do those things, do we need a wasted-work counter at all?
>
> > The wasted work counter works well to respond to heavy read-only
> > traffic and also avoids wasted compressions for write-heavy workloads.
> > So I still like it the best.
>
> This argument presumes that maintenance of the counter is free,
> which it surely is not.  I don't know how bad contention on that
> atomically-updated variable could get, but it seems like it could
> be an issue when lots of processes are acquiring snapshots.

I understand. I was assuming that you and Andres liked that approach.

In the absence of that approach, falling back to a counter that
compresses every N xids would be best, in addition to the two new
forced compression events.

-- 
Simon Riggs                http://www.EnterpriseDB.com/



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

Предыдущее
От: Maxim Orlov
Дата:
Сообщение: Re: [BUG] FailedAssertion in SnapBuildPurgeOlderTxn
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum