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

Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Gregory Stark <gsstark(at)mit(dot)edu>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum
Date: 2007-02-01 02:44:48
Message-ID: 200702010244.l112imf09520@momjian.us (view raw or flat)
Thread:
Lists: pgsql-patches
Have you gotten performance numbers on this yet?

---------------------------------------------------------------------------

Gregory Stark wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> 
> > Tom Lane wrote:
> > 
> > > In any case I'd like to see some evidence of significant real-world
> > > benefit before adding such a conceptual wart ...
> > 
> > I've asked our testers to do a TPC-C run with and without the
> > patch. I'm not expecting it to make a huge difference there, but if you're
> > using a big cost delay, it could make quite a difference for such a simple
> > thing.
> 
> I think the key here is that it removes the size of the table from the list of
> factors that govern the steady-state. Currently as the table grows the maximum
> age of the snapshot vacuum uses gets older too which means a greater
> percentage of the table is dedicated to dead tuple overhead. (which in turn
> means a larger table which means an even greater percentage of dead tuples...)
> 
> With the patch the size of the table is no longer a factor. As long as the
> work vacuum has on a given page can keep up with the rate of creating dead
> tuples then it won't matter how large the table is. The only factors that
> determine the steady state are the rate of creation of dead tuples and the
> rate at which vacuum can process them.
> 
> Unfortunately indexes, again, mean that's not entirely true. As the table
> grows the indexes will grow as well and that will slow vacuum down. Though
> indexes are usually smaller than tables.
> 
> -- 
>   Gregory Stark
>   EnterpriseDB          http://www.enterprisedb.com
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org

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

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

In response to

Responses

pgsql-patches by date

Next:From: Bruce MomjianDate: 2007-02-01 02:45:27
Subject: Re: [pgsql-patches] [HACKERS] [Fwd: Index Advisor]
Previous:From: Bruce MomjianDate: 2007-02-01 02:38:36
Subject: Re: DROP FUNCTION failure: cache lookup failed for relation X

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