Re: TransactionIdIsInProgress() cache

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: TransactionIdIsInProgress() cache
Date: 2008-03-11 17:27:58
Message-ID: 1205256478.4285.11.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Tue, 2008-03-11 at 12:57 +0000, Heikki Linnakangas wrote:

> We could do this instead:
>
> > if (TransactionIdDidCommit(xvac))
> > {
> > /* committed */
> > }
> > else if (!TransactionIdIsInProgress(xvac))
> > {
> > if (TransactionIdDidCommit(xvac))
> > {
> > /* committed */
> > }
> > else
> > {
> > /* aborted */
> > }
> > }
> > else
> > {
> > /* in-progress */
> > }
>
> (hopefully there would be a way to macroize that or something to avoid
> bloating the code any more.)
>
> For committed transactions, this would save the
> TransactionIdIsInProgress call completely, whether or not it's in the
> one-item cache. The tradeoff is that we would have to call
> TransactionIdDidCommit twice for aborted transactions.

I thought about doing it the way you suggest but
TransactionIdIsInProgress is the offending code, so thats the part I
tuned. TransactionIdDidCommit uses the single item cache so it seemed
easier to make isolated changes as proposed rather than touching tqual
code in multiple places to do exactly the same thing.

No, I haven't done any formal performance testing on it. It seemed an
obvious hole that everyone would agree we should avoid, since we can do
it so cheaply: one integer comparison against scanning the whole
procarray and taking an LWlock.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2008-03-11 17:31:29 Re: TransactionIdIsInProgress() cache
Previous Message Tom Lane 2008-03-11 17:27:13 Re: Remove FATAL from pg_lzdecompress