From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Astapov <dastapov(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not? |
Date: | 2021-05-13 23:21:57 |
Message-ID: | 1727507.1620948117@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dmitry Astapov <dastapov(at)gmail(dot)com> writes:
> Am I right in thinking that elimination the join condition is actually
> quite important part of the process?
> Could it possibly be the main reason for =ANY/(x IN (..)) not to be
> optimized the same way?
Yup.
> Is it still hard when one thinks about =ANY or (column in (val1, val2,
> val3, ...)) as well?
Yeah. For instance, if you have
WHERE a = b AND a IN (1,2,3)
then yes, you could deduce "b IN (1,2,3)", but this would not give you
license to drop the "a = b" condition. So now you have to figure out
what the selectivity of that is after the application of the partially
redundant IN clauses.
I recall somebody (David Rowley, maybe? Too lazy to check archives.)
working on this idea awhile ago, but he didn't get to the point of
a committable patch.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2021-05-13 23:22:58 | Re: compute_query_id and pg_stat_statements |
Previous Message | Andrew Dunstan | 2021-05-13 23:19:11 | Re: compute_query_id and pg_stat_statements |