Re: 8.2 is 30% better in pgbench than 8.3

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 8.2 is 30% better in pgbench than 8.3
Date: 2007-07-23 16:13:43
Message-ID: 1185207223.4284.253.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2007-07-23 at 12:00 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > The bad thing about having multiple autovacuum daemons active is that
> > you can get two large VACUUMs running at the same time. This gives you
> > the same small-VACUUM-starvation problem we had before, but now the
> > effects of two VACUUMs kill performance even more. I would suggest that
> > we look at ways of queueing, so that multiple large VACUUMs cannot
> > occur. Setting vacuum_cost_delay will still allow multiple large VACUUMs
> > but will make the starvation problem even worse as well. If we allow
> > that situation to occur, I think I'd rather stick to autovac_workers=1.
> > We will still have this potential problem even with HOT.
>
> We already discussed all this to death before feature freeze.

...and starvation has still not been avoided. I like what you have done,
but we still have a problem, whichever release it gets fixed in.

> I'm not
> sure if it's a good idea to try to come up with new heuristics for the
> thing this late. Feel free to work on it for 8.4 though!
>
> I also wonder whether you have noticed the "balancing" code in autovac.
> Whenever more than one autovac workers are running, they split the
> available I/O allocated to them fairly, so that each one delays more
> frequently than if it was running alone. The net effect is supposed to
> be that no matter how many workers are running, your vacuum delay
> settings are respected.

I did and I like it, many thanks.

> In any case, I think a better solution to the starvation problem caused
> by huge tables is not skipping the vacuuming of them, but making it less
> wasteful, for example with the DSM.

Neither of those things prevent starvation though.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-07-23 16:22:56 Re: 8.2 is 30% better in pgbench than 8.3
Previous Message Aurora Sánchez 2007-07-23 16:03:11 Debug a C shared library using Eclipse or Visual C++ 6.0