| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | PgHacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: We probably need autovacuum_max_wraparound_workers |
| Date: | 2012-06-28 02:18:22 |
| Message-ID: | 26822.1340849902@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Yeah, I can't believe I'm calling for *yet another* configuration
> variable either. Suggested workaround fixes very welcome.
> The basic issue is that autovacuum_max_workers is set by most users
> based on autovac's fairly lightweight action most of the time: analyze,
> vacuuming pages not on the visibility list, etc. However, when XID
> wraparound kicks in, then autovac starts reading entire tables from disk
> ... and those tables may be very large.
It doesn't seem to me that this has much of anything to do with
wraparound; that just happens to be one possible trigger condition
for a lot of vacuuming activity to be happening. (Others are bulk
data loads or bulk updates, for instance.) Nor am I convinced that
changing the max_workers setting is an appropriate fix anyway.
I think what you've really got here is inappropriate autovacuum cost
delay settings, and/or the logic in autovacuum.c to try to divvy up the
available I/O capacity by tweaking workers' delay settings isn't working
very well. It's hard to propose improvements without a lot more detail
than you've provided, though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Johnston | 2012-06-28 02:21:30 | Re: We probably need autovacuum_max_wraparound_workers |
| Previous Message | Robert Haas | 2012-06-28 02:16:03 | Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink |