Re: Improvement of procArray.xmin for VACUUM - Mailing list pgsql-patches

From Tom Lane
Subject Re: Improvement of procArray.xmin for VACUUM
Date
Msg-id 5948.1174751302@sss.pgh.pa.us
Whole thread Raw
In response to Re: Improvement of procArray.xmin for VACUUM  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Improvement of procArray.xmin for VACUUM
Re: Improvement of procArray.xmin for VACUUM
Re: Improvement of procArray.xmin for VACUUM
List pgsql-patches
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> It seems to me a lot cleaner to do the reference counting like Tom
> suggested. Increase the refcount on CopySnapshot, and decrease it on
> FreeSnapshot. Assuming that all callers of CopySnapshot free the
> snapshot with FreeSnapshot when they're done with it.

I don't believe we bother at the moment; which is one of the reasons
it'd be a nontrivial patch.  I do think it might be worth doing though.
In the simple case where you're just issuing successive non-cursor
commands within a READ COMMITTED transaction, a refcounted
implementation would be able to recognize that there are *no* live
snapshots between commands and therefore reset MyProc->xmin to 0
whenever the backend is idle.

OTOH, do we have any evidence that this is worth bothering with at all?
I fear that the cases of long-running transactions that are problems
in the real world wouldn't be helped much --- for instance, pg_dump
wouldn't change behavior because it uses a serializable transaction.
Also, at some point a long-running transaction becomes a bottleneck
simply because its XID is itself the oldest thing visible in the
ProcArray and is determining everyone's xmin.  How much daylight is
there really between "your xmin is old" and "your xid is old"?

            regards, tom lane

pgsql-patches by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Improvement of procArray.xmin for VACUUM
Next
From: Bruce Momjian
Date:
Subject: Re: Improvement of procArray.xmin for VACUUM