Robert Haas writes:
> One other thought: should we add some of these queries that have
> exposed bugs in join removal to the regression tests?
I did.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On Tue, Sep 14, 2010 at 8:44 PM, Robert Haas wrote:
> On Tue, Sep 14, 2010 at 7:26 PM, Tom Lane wrote:
>> I wrote:
>>> I think that it's probably sufficient to make remove_rel_from_query run
>>> through the rel's joininfo list looking for pseudoconstant quals, and
>>> push those back into the joi
On Tue, Sep 14, 2010 at 7:26 PM, Tom Lane wrote:
> I wrote:
>> I think that it's probably sufficient to make remove_rel_from_query run
>> through the rel's joininfo list looking for pseudoconstant quals, and
>> push those back into the joininfo lists with a reduced join list. I
>> wonder though i
I wrote:
> I think that it's probably sufficient to make remove_rel_from_query run
> through the rel's joininfo list looking for pseudoconstant quals, and
> push those back into the joininfo lists with a reduced join list. I
> wonder though if there's a better way, or if there are related bugs
> t
I dug into the 9.0 bug reported here:
http://archives.postgresql.org/pgsql-sql/2010-09/msg00035.php
What is happening is that the planner recognizes that the query is
unsatisfiable, because m.ttype is equated to two different constant
values. This results in generating a constant-false RestrictIn
