Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?
Date
Msg-id CAH2-Wznn9bfsu0F+xmfUOyE6ODyFp5UJ1=k8h3ERiJisO7uz7A@mail.gmail.com
Whole thread Raw
In response to Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?  (Peter Geoghegan <pg@bowt.ie>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: make MaxBackends available in _PG_init
Next
From: Masahiko Sawada
Date:
Subject: Re: Column Filtering in Logical Replication