From: | Cédric Villemain <cedric(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: We probably need autovacuum_max_wraparound_workers |
Date: | 2012-06-29 07:11:56 |
Message-ID: | 201206290912.04591.cedric@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le vendredi 29 juin 2012 04:26:42, Tom Lane a écrit :
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > Well, I think it's "plausible but wrong under at least some common
> > circumstances". In addition to seeking, it ignores FS cache effects
> > (not that I have any idea how to account for these mathematically). It
> > also makes the assumption that 3 autovacuum workers running at 1/3 speed
> > each is better than having one worker running at full speed, which is
> > debatable.
>
> Well, no, not really, because the original implementation with only one
> worker was pretty untenable. But maybe we need some concept like only
> one worker working on *big* tables? Or at least, less than max_workers
> of them.
I think it is easier to manage to keep some workers available to work on other
task instead of having all of them doing the same longest job.
pgfincore allows since years to snapshot and restore the OS cache to work
around such issues.
Autovacuum should snapshot the xMB ahead and restore the previous state cache
when done.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2012-06-29 08:24:30 | Re: Notify system doesn't recover from "No space" error |
Previous Message | Simon Riggs | 2012-06-29 07:10:37 | Re: Checkpointer on hot standby runs without looking checkpoint_segments |