Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group