Greg Stark <st...@enterprisedb.com> writes:
> On Tue, Apr 28, 2009 at 4:41 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Another place where planner regression tests might've helped :-(
> I would suggest we start gathering up such tests in an sql file now
> and worry about how to compare the output later.
If anyone feels like doing the legwork, there are interesting examples
in the CVS commit logs. I happened to notice the current problem while
I was re-reading the logs whilst checking the release notes. For no
particularly good reason I retried the examples mentioned in this item,
and behold it wasn't what I expected ...
2008-08-17 15:40 tgl
* src/backend/optimizer/path/joinrels.c: Add some defenses against
constant-FALSE outer join conditions. Since eval_const_expressions
will generally throw away anything that's ANDed with constant
FALSE, what we're left with given an example like
select * from tenk1 a where (unique1,0) in (select unique2,1 from
tenk1 b);
is a cartesian product computation, which is really not acceptable.
This is a regression in CVS HEAD compared to previous releases,
which were able to notice the impossible join condition in this
case --- though not in some related cases that are also improved by
this patch, such as
select * from tenk1 a left join tenk1 b on (a.unique1=b.unique2 and
0=1);
Fix by skipping evaluation of the appropriate side of the outer
join in cases where it's demonstrably unnecessary.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
