Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats.
От | Alvaro Herrera |
---|---|
Тема | Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats. |
Дата | |
Msg-id | 20070608011231.GA20828@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats. (Gregory Stark <stark@enterprisedb.com>) |
Список | pgsql-hackers |
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)
В списке pgsql-hackers по дате отправления: