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.
I'm also starting to come around to liking the page-header-xid field
a bit more. I suggest that it could replace the "page is prunable"
flag bit altogether --- to mark the page prunable, you must store
some appropriate xid into the header field. This would avoid a useless
prune attempt immediately after a page is marked prunable.
A possible problem with it, if we treat it as a non-WAL-logged hint,
is that corruption of the value could lead to a page being marked with
an xid that's way in the future, keeping it from getting pruned.
However, if the page header gets corrupted this is the least of your
worries, so it doesn't seem like an enormous objection.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
