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

From Tom Lane
Subject Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?
Date
Msg-id 2373393.1650310897@sss.pgh.pa.us
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>)
Responses Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> On Mon, Apr 18, 2022 at 12:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Huh?  This is not pg_class.reltuples.  If an index AM wants that, it
>> knows where to find it.

> It's not, but it is how we calculate
> IndexBulkDeleteResult.num_index_tuples, which is related.

Well, the number of entries in an index needn't be exactly the
same as the number in the underlying heap.  If we're setting
an index's reltuples to the number of actual index entries
including dead entries, I don't have a problem with that:
unlike the case for table reltuples, it's not going to result
in bad estimates of the number of rows resulting from a query.
If the planner looks at index reltuples at all, it's doing so
for cost estimation purposes, where the count including dead
entries is probably the right thing to use.

If you want to make this cleaner, maybe there's a case for
splitting reltuples into two columns.  But then index AMs
would be on the hook to determine how many of their entries
are live, which is not really an index's concern.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname
Next
From: Mark Dilger
Date:
Subject: Re: Postgres perl module namespace