Re: Small problem with PlaceHolderVar mechanism - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Small problem with PlaceHolderVar mechanism
Date
Msg-id 5010.1240935533@sss.pgh.pa.us
Whole thread Raw
In response to Re: Small problem with PlaceHolderVar mechanism  (Greg Stark <stark@enterprisedb.com>)
List pgsql-hackers
Greg Stark <stark@enterprisedb.com> writes:
> On Tue, Apr 28, 2009 at 4:41 PM, Tom Lane <tgl@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 againstconstant-FALSE outer join conditions.  Since
eval_const_expressionswillgenerally throw away anything that's ANDed with constantFALSE, what we're left with given an
examplelikeselect * from tenk1 a where (unique1,0) in (select unique2,1 fromtenk1 b);is a cartesian product
computation,which is really not acceptable. This is a regression in CVS HEAD compared to previous releases,which were
ableto notice the impossible join condition in thiscase --- though not in some related cases that are also improved
bythispatch, such asselect * from tenk1 a left join tenk1 b on (a.unique1=b.unique2 and0=1);Fix by skipping evaluation
ofthe appropriate side of the outerjoin in cases where it's demonstrably unnecessary.
 
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: idea: global temp tables
Next
From: Tom Lane
Date:
Subject: Re: Small problem with PlaceHolderVar mechanism