Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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>

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

In response to


pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group