From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dmitry Astapov <dastapov@gmail.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Condition pushdown: why (=) is pushed down into join,
 but BETWEEN or >= is not?
In-reply-to: 
 <CAFQUnFiQJJctiZd_vO5Tt8yN=H9Pwpg4AfzcyRCCmEz6jnmAvQ@mail.gmail.com>
References: 
 <CAFQUnFhqkWuPCwQ1NmHYrisHJhYx4DoJak-dV+FcjyY6scooYA@mail.gmail.com>
 <1099349.1620834846@sss.pgh.pa.us>
 <CAFQUnFiQJJctiZd_vO5Tt8yN=H9Pwpg4AfzcyRCCmEz6jnmAvQ@mail.gmail.com>
Comments: In-reply-to Dmitry Astapov <dastapov@gmail.com>
	message dated "Wed, 12 May 2021 18:56:00 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1727506.1620948117.1@sss.pgh.pa.us>
Date: Thu, 13 May 2021 19:21:57 -0400
Message-ID: <1727507.1620948117@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1727507.1620948117%40sss.pgh.pa.us>
Precedence: bulk

Dmitry Astapov <dastapov@gmail.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