Re: Slow standby snapshot - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Slow standby snapshot
Date
Msg-id CANbhV-FL4wjeb2AjEdSUf5J3QToWpoSnm4rLQhffCzL6P9z4-Q@mail.gmail.com
Whole thread Raw
In response to Re: Slow standby snapshot  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Slow standby snapshot
List 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 by date:

Previous
From: Maxim Orlov
Date:
Subject: Re: [BUG] FailedAssertion in SnapBuildPurgeOlderTxn
Next
From: Andres Freund
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum