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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Why does pg_class.reltuples count only live tuples in indexes (after VACUUM runs)?
Date: 2022-04-18 19:41:37
Message-ID: 2373393.1650310897@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Mon, Apr 18, 2022 at 12:15 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2022-04-18 19:46:09 Re: Postgres perl module namespace
Previous Message Mark Dilger 2022-04-18 19:39:17 Re: pg14 psql broke \d datname.nspname.relname