Re: Does pg_stat_get_live_tuples() matter?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Does pg_stat_get_live_tuples() matter?
Дата
Msg-id 1935.1554869432@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Does pg_stat_get_live_tuples() matter?  (Sherrylyn Branchaw <sbranchaw@gmail.com>)
Ответы Re: Does pg_stat_get_live_tuples() matter?  (Sherrylyn Branchaw <sbranchaw@gmail.com>)
Список pgsql-general
Sherrylyn Branchaw <sbranchaw@gmail.com> writes:
> If a table has 1.8M rows in reality, yet pg_stat_get_live_tuples() returns
> 1.8K, does it matter to the performance of the database, as long as
> pg_class.reltuples is the right order of magnitude?

Hmmm ... what was in reltuples again?  Looking at the current code,
it looks like vacuum or autovacuum should set reltuples and n_live_tuples
to the same thing.  n_live_tuples gets adjusted incrementally by
subsequent transactions, and it wouldn't be too surprising if it drifted
away from reality, but it's a bit hard to believe that it could get to be
off by 1000X.  Have you suppressed autovacuum on this table?

We have fooled around with the logic that maintains these numbers, so
maybe it was different in 9.6.9.

Anyway, to answer your question, I don't see anything in the current core
code that pays attention to n_live_tuples.  reltuples definitely does
matter to the planner, and some of the sibling counters like n_dead_tuples
drive autovacuum, but nothing is examining n_live_tuples AFAICS.

            regards, tom lane



В списке pgsql-general по дате отправления:

Предыдущее
От: Igal Sapir
Дата:
Сообщение: Re: Unable to Vacuum Large Defragmented Table
Следующее
От: Jess Wren
Дата:
Сообщение: Re: How to use full-text search URL parser to filter query results bydomain name?