| From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Bernd Helmle <mailings(at)oopsware(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: tuning autovacuum |
| Date: | 2011-06-09 22:29:36 |
| Message-ID: | 4DF14950.3000705@2ndQuadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 06/09/2011 05:41 PM, Tom Lane wrote:
> As Robert said, we're already seeing scalability problems with the
> pg_stats subsystem. I'm not eager to add a bunch more per-table
> counters, at least not without some prior work to damp down the ensuing
> performance hit.
>
That's fair. Anyone who is running into the sort of autovacuum issues
prompting this discussion would happily pay the overhead to get better
management of that; it's one of the easiest things to justify more
per-table stats on IMHO. Surely the per-tuple counters are vastly more
of a problem than these messages could ever be.
But concerns about stats overload are why I was highlighting issues
around sending multiple messages per vacuum, and why incremental updates
as it runs are unlikely to work out. Balancing that trade-off, getting
enough data to help but not so such the overhead is obnoxious, is the
non obvious tricky part of the design here.
--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-06-09 22:37:36 | Re: tuning autovacuum |
| Previous Message | Florian Pflug | 2011-06-09 22:26:30 | Re: Range Types and extensions |