Re: HOT is applied - Mailing list pgsql-hackers

From Robert Treat
Subject Re: HOT is applied
Date
Msg-id 200709231016.45069.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: HOT is applied  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: HOT is applied
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCHES] Eliminate more detoast copies for packed varlenas
Next
From: Robert Treat
Date:
Subject: Re: Beginning Tamil Community for Postgre