Tom Lane wrote:
> 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.
Good point.
I noted that most callers of TransactionIdIsInProgress in tqual.c
already call TransactionIdIsCurrentTransactionId before
TransactionIdIsInProgress. In those cases we could just skip the test
for our own xids altogether, if it's worth code mangling to tell
TransactionIdIsInProgress whether it's safe to skip it or not.
> 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.
Yeah, we don't need the flag if we have an xid.
> 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.
Agreed. Next attempt to prune or vacuum the page will fix it anyway.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
