Tomas Vondra writes:
> But dependencies.c might need a fix too, although the issue is somewhat
> inverse to this one, because it looks like this:
> if (IsA(clause, RestrictInfo))
> {
> ... do some checks ...
> }
> so if there's no RestrictInfo on top, we just accept the claus
On 4/20/22 16:15, Tom Lane wrote:
> Tomas Vondra 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
Tomas Vondra wrote:
> Andre, are you in position to test this fix with your application? Which
> Postgres version are you using, actually?
There's a test case in my original email, which obviously was synthetic, but I
could also test this with my original
application data if I can get a Postgres
Tomas Vondra 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.
On 4/20/22 09:58, Tomas Vondra wrote:
> On 4/19/22 23:08, Tom Lane wrote:
>> I wrote:
>>> it looks like the problem is that the extended stats haven't been used
>>> while forming the estimate of the number of index entries retrieved, so
>>> we overestimate the cost of using this index.
>>> That s
On 4/19/22 23:08, Tom Lane wrote:
> I wrote:
>> it looks like the problem is that the extended stats haven't been used
>> while forming the estimate of the number of index entries retrieved, so
>> we overestimate the cost of using this index.
>> That seems like a bug. Tomas?
>
> I dug into this e
I wrote:
> it looks like the problem is that the extended stats haven't been used
> while forming the estimate of the number of index entries retrieved, so
> we overestimate the cost of using this index.
> That seems like a bug. Tomas?
I dug into this enough to locate the source of the problem.
b
=?iso-8859-1?Q?Andr=E9_H=E4nsel?= writes:
> I have a case where Postgres chooses the wrong index and I'm not sure what
> to do about it:
The core problem here seems to be a poor estimate for the selectivity
of "WHERE cropped AND NOT resized":
regression=# EXPLAIN ANALYZE
SELECT count(*) FROM t
W
