From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(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:22:56 |
Message-ID: | 20070723162256.GE2540@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
> 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.
> >
> > 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.
Oh I will the first to admit that autovacuum is still not "good enough".
> > 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.
Certainly it doesn't prevent starvation completely -- really there is no
way to completely prevent starvation unless you have as many workers as
you have tables, and one disk for each. What DSM does do is let the big
tables be vacuumed quickly which makes most of the problem go away.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2007-07-23 16:30:07 | Re: Full page images in WAL & Cache Invalidation |
Previous Message | Simon Riggs | 2007-07-23 16:13:43 | Re: 8.2 is 30% better in pgbench than 8.3 |