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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum