Re: BUG #16558: `AND FALSE` increases planning time of query on 2 tables with 1000 partitions to more than 7 seconds

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Wed, 29 Jul 2020 at 03:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> What seems to be happening here is that expression simplification reduces
>> the WHERE clause to just constant-false, ie
>> SELECT * FROM demo1 JOIN demo2 ON demo1.key2 = demo2.key2 WHERE FALSE;

> I wonder if we could maybe cheaply do something better for this case.

I'd wondered about that too, but it seems like there's no way that it's
not going to penalize every query in order to improve abysmally stupid
queries. I will never buy that an ORM should be allowed to issue WHERE
FALSE (rather than suppressing issuance of the query altogether) and
expect that somebody else will mop up after its astonishing laziness.
So I'm not big on adding complexity and cycles to something as critical
as distribute_qual_to_rels to deal with it.

FWIW, the existing "pseudoconstant" support is called that because in
most useful queries, what it's dealing with is not actually a constant
in this sense, but something that will require run-time evaluation.
So the majority of that logic is dealing with real, useful query cases,
and there is little if any that is optimizing WHERE FALSE per se.

regards, tom lane