Date: Tue, 18 Jan 2022 11:07:19 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: James Coleman <jtc331@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Add last commit LSN to pg_last_committed_xact()
Message-ID: <202201181407.gpu6ivyddgkw@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+TgmoZc02mC5H=tUm5v9fxZAKfYibD8Kje4pze-p6E_WmBiVQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202201181407.gpu6ivyddgkw%40alvherre.pgsql>
Precedence: bulk

On 2022-Jan-17, Robert Haas wrote:

> On Mon, Jan 17, 2022 at 4:34 PM Alvaro Herrera <alvherre@alvh.no-ip.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/