Skip site navigation (1) Skip section navigation (2)

Re: TransactionIdIsInProgress() cache

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: TransactionIdIsInProgress() cache
Date: 2008-03-11 19:11:09
Message-ID: 2311.1205262669@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> 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.

[ after reading the patch a bit closer... ]  Actually, it's not as
obvious as all that.  TransactionIdIsInProgress already falls out before
the proposed test for any XID < RecentXmin, which means that in reality
it's fairly probable that the target XID is running.  So while this test
may not cost much, it's not clear that it really buys much either.

I'm going to go ahead and apply it, but it'd be good if someone would
verify that it at least doesn't cost anything on some real benchmarks.

BTW, I think we should put it in front of, not after, the
TransactionIdIsCurrentTransactionId test, since as was just being
discussed that could have nontrivial execution time.  (I'll go look at
Heikki's improvement on that next, but it'll still be not-free if
there's lots of subtransactions.)

			regards, tom lane

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2008-03-11 19:32:30
Subject: Re: TransactionIdIsInProgress() cache
Previous:From: Cliff NieuwenhuisDate: 2008-03-11 19:07:40
Subject: Re: encoding problems

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group