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

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