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

On Fri, 31 Jul 2020 at 12:46, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.

hmm ok. FWIW, I did have in mind that the FALSE had been constant
folded from something more complex. I don't really have any particular
interest in speeding up the queries that actually actually write WHERE
false. It's just constant folding has already been done by this time
so we can't really know if the qual was something more legitimate
prior to the folding.

David