Re: Improvement of procArray.xmin for VACUUM

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Improvement of procArray.xmin for VACUUM
Date: 2007-03-27 02:11:32
Message-ID: 200703270211.l2R2BWS09883@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> ... 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.
>
> Uh, no, that's not very clear. A long-running transaction will be a
> VACUUM bottleneck because of its own XID, never mind its xmin. To make
> this helpful, you have to posit a lot of overlapping long-running
> transactions (such that the distance back to GlobalXmin might average
> about twice the distance back to the oldest live XID). That's not
> impossible but I wonder whether it's not mostly a token of bad
> application design.

Well, my secondary addition was to start MyProc->xmin with the current
xid counter, rather than your own xid. This is because your xid is
already in progress and so will not be touched, so why not start with
the current xid counter.

--
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. +

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2007-03-27 02:12:39 Re: Improvement of procArray.xmin for VACUUM
Previous Message Bruce Momjian 2007-03-27 02:09:00 Re: patch adding new regexp functions