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@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
