public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Andres Freund <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Julien Rouhaud <[email protected]>
Cc: Simon Riggs <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: Pengchengliu <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: suboverflowed subtransactions concurrency performance optimize
Date: Sat, 28 May 2022 15:21:58 +0900
Message-ID: <YpG/[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CANbhV-GdpdpkvgAaRgaLsKQjTOdoGDXpCJkKU7wLrUBthTC_qQ@mail.gmail.com>
<CANbhV-G8Co=yq4v4BkW7MJDqVt68K_8A48nAZ_+8UQS7LrwLEQ@mail.gmail.com>
<20220307094855.kkc6vagshyc6xsbn@jrouhaud>
<CANbhV-E9eFXNuN-NMnH5xjRDGAM+Vi8+CUi5c3cXgeo93NM9Aw@mail.gmail.com>
<20220307141741.6jidhra3tup6uiaf@jrouhaud>
<[email protected]>
<[email protected]>
<[email protected]>
<CAA4eK1L7ou9=EJYBDsrzqeCw2dO_RLUMjsMFxJAESc5tyb_S1A@mail.gmail.com>
<[email protected]>
On Fri, May 27, 2022 at 08:55:02AM -0700, Andres Freund wrote:
> On 2022-05-27 15:44:39 +0530, Amit Kapila wrote:
>> Won't in theory the similar cache in transam.c is also prone to
>> similar behavior?
TransactionIdDidCommit() and TransactionIdDidAbort() are used in much
more code paths for visibility purposes, contrary to the subtrans.c
ones.
> It's not quite the same risk, because there we are likely to actually hit the
> cache regularly. Whereas quite normal workloads might not hit this cache for
> days on end.
Yeah. In short, this mostly depends on the use of savepoints and the
number of XIDs issued until PGPROC_MAX_CACHED_SUBXIDS is reached, and
a single cache entry in this code path would reduce the pressure on
the SLRU lookups depending on the number of queries issued, for
example. One thing I know of that likes to abuse of savepoints and
could cause overflows to make this easier to hit is the ODBC driver
coupled with short queries in long transactions, where its internals
enforce the use of a savepoint each time a query is issued by an
application (pretty much what the benchmark at the top of the thread
does). In this case, even the single cache approach would not help
much because I recall that we finish with one savepoint per query to
be able to rollback to any previous state within a given transaction
(as the ODBC APIs allow).
Doing a caching within SubTransGetParent() would be more interesting,
for sure, though the invalidation to clean the cache and to make that
robust enough may prove tricky.
It took me some time to come back to this thread. The change has now
been reverted.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../YpG%[email protected]/2-signature.asc)
download
view thread (30+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: suboverflowed subtransactions concurrency performance optimize
In-Reply-To: <YpG/[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox