Have you gotten performance numbers on this yet?

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

Gregory Stark wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> 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   [EMAIL PROTECTED]
  EnterpriseDB    http://www.enterprisedb.com

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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

Reply via email to