Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
От | Alvaro Herrera |
---|---|
Тема | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |
Дата | |
Msg-id | 1306342228-sup-2964@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
|
Список | pgsql-hackers |
Excerpts from Kevin Grittner's message of mié may 25 12:37:24 -0400 2011: > Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > I don't know what client-side code might be looking at > > relpages/reltuples. > > I know that I find reltuples useful for getting an "accurate enough" > sense of rows in a table (or set of tables) without resorting to > count(*). I'd be OK with any two of pages, tuples, and density; but > dropping to one would make databases harder to manage, IMV. > > Personally, I don't have much code that uses those columns; > eliminating an existing column wouldn't involve much pain for me as > long as it could still be derived. Well, we only actually need to store one number, because you can figure out a much more precise number-of-pages figure with pg_relation_size() divided by configured page size. (We feel free to hack around catalogs in other places, and we regularly break pgAdmin and the like when we drop columns -- people just live with it and update their tools. I don't think it's such a big deal in this particular case.) -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: