Re: apply outer->inner join optimisation to OR clauses

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bradley Baetz <bbaetz(at)acm(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: apply outer->inner join optimisation to OR clauses
Date: 2003-05-04 14:27:28
Message-ID: 27683.1052058448@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Bradley Baetz <bbaetz(at)acm(dot)org> writes:
> Or are we guaranteed that there wont' be OR/AND expressions
> inside a NOT, because they will have always been expanded?

No, we're not, because the CNF-ifying code is optional. If you study
the heuristics in prepqual.c you could doubtless devise a query that has
such an expression somewhere in it.

Even if that was a safe assumption today, writing code that would fail
in as subtle a way as this when presented with such a tree won't do.
The optimizer gets revamped constantly, and so I don't want to see any
assumptions that fragile embedded into pieces of it.

> Do we agree that if the thing inside the NOT is a single expression,
> then what I've doing is safe? IS it safe even if theres and/or involved
> as the argument to a (strict) operator?

I'm going to take the position "fix it right or don't touch it at all".
The routine as it stands does what it was intended to do. If you want
to invest the effort to take it to the next level of intelligence, great
--- but let's not put in a half-baked attempt.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Ben Lamb 2003-05-04 20:54:18 Patch for PGunescapeBytea
Previous Message Tom Lane 2003-05-04 14:05:30 Re: Disable alternate locations on Win32