Simon Riggs <[EMAIL PROTECTED]> 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
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
