|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
> 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
|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|