Greg Stark <gsstark(at)mit(dot)edu> wrote:
> Kevin Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> impossible to write two queries which can be shown to be logically
>> equivalent but which optimize to different access plans
>
> Personally I think that's a fine goal to aim for.
Sure, but from my experience, there aren't any database products which
come close to having an optimizer which can do a good enough job that
it is yet feasible. I'm not sure I've even seen any which reliably
treat '(a AND b) OR (c and d)' as equivalent to 'NOT ((a OR b) AND (c
OR d))', much less the fairly common 'a > b OR (a = b AND c > d)' into
'a >= b AND (a > b OR c > d)'. Two commonly heard arguments on this
list are that:
(1) a particular improvement in this area is not worth it because it
would cost more in CPU time to recognize the equivalence that it would
save in run time from the better plan, and
(2) someone sometimes finds it useful to not recognize the equivalence
so that they can coerce a certain type of plan.
The latter really *is* a form of optimizer hint, it's just an
undocumented, arcane hint for the Illuminati.
But anyway, I didn't say that it was a bad thing toward which to
strive, just that it's so far from realization that as an absolute
requirement to be designated an RDBMS, it's a bit "ivory tower."
> I'm not sure what "to be considered a relational database" means
In that context I was talking about Codd's book where he provides a
list of properties which a DBMS should have to be considered, in his
opinion (as the inventor of the relational model for database
management) a relational database management system. It just occurs
to me that I think some of these entries were *required* for his
blessing, and others were just *desirable*. I don't remember which
designation he gave this point.
-Kevin