Re: Small problem with PlaceHolderVar mechanism
От | Tom Lane |
---|---|
Тема | Re: Small problem with PlaceHolderVar mechanism |
Дата | |
Msg-id | 5010.1240935533@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Small problem with PlaceHolderVar mechanism (Greg Stark <stark@enterprisedb.com>) |
Список | 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 по дате отправления: