From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
Subject: | Re: HOT is applied |
Date: | 2007-09-23 14:16:44 |
Message-ID: | 200709231016.45069.xzilla@users.sourceforge.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2007-09-23 14:21:40 | Re: Beginning Tamil Community for Postgre |
Previous Message | Andrew Dunstan | 2007-09-23 13:09:50 | Re: [PATCHES] Eliminate more detoast copies for packed varlenas |