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 g...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
