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

From Bruce Momjian
Subject Re: Improvement of procArray.xmin for VACUUM
Date
Msg-id 200703262344.l2QNisT19765@momjian.us
Whole thread Raw
In response to Re: Improvement of procArray.xmin for VACUUM  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Improvement of procArray.xmin for VACUUM  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
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@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [pgsql-patches] [HACKERS] less privileged pl install
Next
From: Gregory Stark
Date:
Subject: Re: Improvement of procArray.xmin for VACUUM