Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?
Дата
Msg-id CAH2-Wznn9bfsu0F+xmfUOyE6ODyFp5UJ1=k8h3ERiJisO7uz7A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Mon, Apr 18, 2022 at 1:12 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I would argue that it would be correct for the first time -- at least
> if we take the behavior within heapam_index_build_range_scan (and
> everywhere else) as authoritative. That's a feature, not a bug.

Attached draft patch shows what I have in mind. I think that the issue
should be treated as a bug, albeit a minor one that's not worth
backpatching. I would like to target Postgres 15 here.

Addressing this issue allowed me to move more state out of vacrel.
This patch continues the trend of moving everything that deals with
pg_class, statistics, or instrumentation from lazy_scan_heap into its
caller, heap_vacuum_rel().

I noticed GIN gives us another reason to go this way:
ginvacuumcleanup() always instructs lazyvacuum.c to set each GIN
index's pg_class.reltuples to whatever the value is that will be set
in the heap relation, even with a partial index. So defining reltuples
differently for indexes just doesn't seem reasonable to me. (Actually,
lazyvacuum.c won't end up setting the value in the GIN index's
pg_class entry when IndexVacuumInfo.estimated_count is set to true.
But that hardly matters -- either way, num_index_tuples comes from
num_heap_tuples in a GIN index, no matter what.)

-- 
Peter Geoghegan

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: make MaxBackends available in _PG_init
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Column Filtering in Logical Replication