Re: Bad estimate with partial index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: André Hänsel <andre(at)webkr(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Bad estimate with partial index
Date: 2022-04-20 14:15:57
Message-ID: 2823861.1650464157@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> The whole idea is that instead of bailing out for non-RestrictInfo case,
> it calculates the necessary information for the clause from scratch.
> This means relids and pseudoconstant flag, which are checked to decide
> if the clause is compatible with extended stats.

Right.

> But when inspecting how to calculate pseudoconstant, I realized that
> maybe that's not really needed. Per distribute_qual_to_rels() we only
> set it to 'true' when bms_is_empty(relids), and we already check that
> relids is a singleton, so it can't be empty - which means pseudoconstant
> can't be true either.

Yeah, I would not bother with the pseudoconstant-related tests for a
bare clause. Patch looks reasonably sane in a quick once-over otherwise,
and the fact that it fixes the presented test case is promising.
(If you set enable_indexscan = off, you can verify that the estimate
for the number of index entries retrieved is now sane.) I did not look
to see if there were any other RestrictInfo dependencies, though.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message André Hänsel 2022-04-20 14:23:26 RE: Bad estimate with partial index
Previous Message Robert Haas 2022-04-20 14:13:53 Re: Re: fix cost subqueryscan wrong parallel cost