Re: We probably need autovacuum_max_wraparound_workers - Mailing list pgsql-hackers

From Cédric Villemain
Subject Re: We probably need autovacuum_max_wraparound_workers
Date
Msg-id 201206290912.04591.cedric@2ndquadrant.com
Whole thread Raw
In response to Re: We probably need autovacuum_max_wraparound_workers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Le vendredi 29 juin 2012 04:26:42, Tom Lane a écrit :
> Josh Berkus <josh@agliodbs.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

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Checkpointer on hot standby runs without looking checkpoint_segments
Next
From: Christoph Berg
Date:
Subject: Re: Notify system doesn't recover from "No space" error