Gregory Stark wrote:
> "Alvaro Herrera" <alvherre@commandprompt.com> writes:
>
> > Gregory Stark wrote:
> >
> > > is it possible it's related to the performance drop immediately
> > > following a vacuum analyze we've been seeing?
> >
> > I don't think so, unless you were counting on pgstats data of shared
> > tables for something. The optimizer, for one, doesn't, so I doubt it
> > would affect query planning. And it would only affect you if your
> > queries were using shared tables, which I very much doubt ...
>
> Does anything use the pgstats data for anything other than presenting feedback
> to users?
Not that I know of.
> Autovacuum uses it to estimate when tables should be vacuumed right?
Yep
> This wouldn't have caused autovacuum to go nuts vacuuming these tables
> would it? But I doubt even then that it could consume much i/o
> bandwidth.
Yes but keep in mind that these are only the shared tables: pg_database,
pg_authid, pg_shdepend, etc. Those are not tables that you're going to
use regularly, much less _bloat_ regularly that they need frequent
vacuuming.
Maybe pg_shdepend, because it would be used when creating temp tables.
--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"Postgres is bloatware by design: it was built to housePhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)