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
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 |