Re: BUG #16993: Query Planner does not use index for EXISTS-query on a large table with all equal foreign key values - Mailing list pgsql-bugs

From David Rowley
Subject Re: BUG #16993: Query Planner does not use index for EXISTS-query on a large table with all equal foreign key values
Date
Msg-id CAApHDvqvQ2mQZ36Gkz+qbC8e98ShVscF0aiB6TXHN=5uiXWOQg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16993: Query Planner does not use index for EXISTS-query on a large table with all equal foreign key values  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #16993: Query Planner does not use index for EXISTS-query on a large table with all equal foreign key values  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, 6 May 2021 at 15:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yeah, I agree that it doesn't seem great to let var_eq_non_const return
> 1.0 when it has no idea what the comparison value is.  However, that
> doesn't translate to having much confidence in any other value either.
> The actual number-of-rows-fetched, given that we know the column
> contents are all the same value, is either zero or the whole table.
> It's hard to do much with that; and biasing it towards believing the
> optimistic value over the pessimistic value seems dangerous.

Maybe we should be also looking at var_eq_non_const()'s 'other' field
and seeing if that's a Var with stats and dividing the results by the
number of distinct values in that, or at least doing something closer
to what eqjoinsel_inner() does when it's prompted with the same
problem.

David



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16993: Query Planner does not use index for EXISTS-query on a large table with all equal foreign key values
Next
From: Tom Lane
Date:
Subject: Re: BUG #16993: Query Planner does not use index for EXISTS-query on a large table with all equal foreign key values