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