On Friday 21 September 2007 13:02, Tom Lane wrote:
> I wrote:
> > Dunno about "more general", but your idea reduces the runtime of this
> > example by about 50% (22.2s to 10.5s) for me. I'm worried though that
> > it would be a net negative in more typical situations, especially if
> > you've got a lot of open subtransactions.
>
> Actually ... the only way that TransactionIdIsCurrentTransactionId can
> take a meaningful amount of time is if you've got lots of
> subtransactions, and in that case your own subxids cache has certainly
> overflowed, which is likely to force TransactionIdIsInProgress into the
> "slow answer" path. But if we use TransactionIdIsCurrentTransactionId
> to handle our own xids then we can just ignore MyProc altogether inside
> the loop, thus very possibly (if we are the only overflowed-subxids proc)
> saving us from going through the slow answer path. So on reflection
> I can't see how this isn't a win. I'll clean it up and apply it.
>
Just curious, but does this apply to subtransactions that are the result of
plpgsql try...exception blocks? And how many is lots? Presumably looping 50k
times in a single procedure would be enough?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
