Re: Optimizing TransactionIdIsCurrentTransactionId() - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Optimizing TransactionIdIsCurrentTransactionId()
Date
Msg-id CANP8+jKzMEBLkSpCAKeny7ahq5JR2uyV1Xs4UtV5JEyRqNuU+w@mail.gmail.com
Whole thread Raw
In response to Re: Optimizing TransactionIdIsCurrentTransactionId()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Optimizing TransactionIdIsCurrentTransactionId()  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, 19 Dec 2019 at 19:27, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Dec 18, 2019 at 5:07 AM Simon Riggs <simon@2ndquadrant.com> wrote:
> TransactionIdIsCurrentTransactionId() doesn't seem to be well optimized for the case when an xid has not yet been assigned, so for read only transactions.
>
> A patch for this is attached.

It might be an idea to first call TransactionIdIsNormal(xid), then
GetTopTransactionIdIfAny(), then TransactionIdIsNormal(topxid), so
that we don't bother with GetTopTransactionIdIfAny() when
!TransactionIdIsNormal(xid).

But it's also not clear to me whether this is actually a win. You're
dong an extra TransactionIdIsNormal() test to sometimes avoid a
GetTopTransactionIdIfAny() test.

That's not the point of the patch.

If the TopTransactionId is not assigned, we can leave the whole function more quickly, not just avoid a test.

Read only transactions should have a fast path thru this function since they frequently read more data than write transactions.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Solutions for the Enterprise

pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Disallow cancellation of waiting for synchronous replication
Next
From: Masahiko Sawada
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions