Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Tom Lane wrote:
> >> I'm wondering about doing something similar to what
> >> TransactionIdIsInProgress does, ie, make use of the PGPROC lists
> >> of live subtransactions.
>
> > Well, that sounds awfully more expensive than setting
> > local-to-my-database Xmins as well as global (all databases) Xmins :-)
>
> Only when you've got a lot of subtransactions. The point of this
> discussion is to optimize for the few-or-none case. In any case,
> the problem with the local/global bit was that you'd be expending
> foreground-process cycles without any foreground-process return.
> Being able to use a snapshot without consulting pg_subtrans will
> certainly buy back some cycles...
I can buy that. Some idle thoughts:
I was thinking at what time was the most appropiate to insert or remove
an Xid from the cache. We can do without any excl-locking because 1) we
already assume the storing of an Xid to be atomic, and 2) no one can be
interested in querying for an Xid before the originating transaction has
had the chance to write a tuple with that Xid anyway.
OTOH I think we only need to store live Xids and those finished that
wrote a WAL record; we can drop subaborted and subcommitted if they
didn't.
On the third hand, are we going to sh-acquire the ProcArray lock while a
GetSnapshotData copies all subxact Xids of all running transactions?
ProcArrayLock will become more of a contention point than it already is.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support