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:
> hmm ok. FWIW, I did have in mind that the FALSE had been constant
> folded from something more complex.

Hm. Maybe that's a legitimate argument, not sure. But I'd still
rather find someplace that's less critical performance-wise if we're
going to try to hack up this case.

I also wonder about cases like

select * from (t1 join t2 on false) join t3 on t1.x=t3.y;

If we were taking this seriously, it'd be nice to deduce that
(1) the t1/t2 join is empty and (2) therefore so is the join
to t3, so (3) we need not build paths for any of these base rels.
I think the syntactically-driven method you're proposing would
not catch that, which'd be problematic if t3 is the giant
partitioned rel.

[ wanders away wondering if reduce_outer_joins could be taught
to do this... ]

regards, tom lane