Re: Improvement of procArray.xmin for VACUUM

Tom Lane wrote:
> On the whole though I think we should let this idea go till 8.4; we have
> a lot to deal with for 8.3 and a definite shortage of evidence that
> advancing xmin will buy much. Mu gut feeling is that the above design
> would save about enough in snapshot-copying costs to pay for its extra
> management logic, but we won't come out ahead unless advancing xmin
> intra-transaction really helps, and I'm not sure I believe that (except
> in the special case of VACUUM, and we already have a solution for that,
> which would be independent of this).

The improvement is going to be a win for multi-statement transactions
--- the only question is how often are they long-running.

It does seem best to put this on the TODO for 8.4, and I will do that
now. The only thing that makes it tempting to get into 8.3 is that we
could advertise this release as a major "space reuse" release because of
HOT, autovacuum on by default, multiple autovacuum processes, and, if we
added it, improved VACUUM for multi-statement transactions.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +