From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add last commit LSN to pg_last_committed_xact() |
Date: | 2022-01-18 14:07:19 |
Message-ID: | 202201181407.gpu6ivyddgkw@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2022-Jan-17, Robert Haas wrote:
> On Mon, Jan 17, 2022 at 4:34 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > Maybe it would work to have a single LSN in shared memory, as an atomic
> > variable, which uses monotonic advance[1] to be updated. Whether this is
> > updated or not would depend on a new GUC, maybe track_latest_commit_lsn.
> > Causing performance pain during transaction commit is not great, but at
> > least this way it shouldn't be *too* a large hit.
>
> I don't know if it would or not, but it's such a hot path that I find
> the idea a bit worrisome. Atomics aren't free - especially inside of a
> loop.
I think the aspect to worry about the most is what happens when the
feature is disabled. The cost for that should be just one comparison,
which I think can be optimized by the compiler fairly well. That should
be cheap enough. People who enable it would have to pay the cost of the
atomics, which is of course much higher.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-01-18 14:11:10 | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |
Previous Message | Alvaro Herrera | 2022-01-18 13:24:34 | Re: missing indexes in indexlist with partitioned tables |