I don't have enough experience with the code to know how/why/where it does it's thinking. I personally don't have anything that I think will benefit
from "stupidity eliminators". A few that pop into my head are (Again, these may be handled appropriately):

Select Field1, Field2
From Table1
Where Field1 = Field2 or Field2 = Field1;

Select Table1.Field1, Table2.Field2
From Table1 Inner Join Table2 on Table1.Field1 = Table2.Field1
Where Table1.Field1 = Table2.Field1;

Select Field1, Field2
From Table1
Where Field1 in
(
Select Field1
From Table1
);

I could come up with a billion more. The deriviatives that could be produced from the examples amount in multitudes. More or less, all of these
queries have things to them that do not affect the outcome of the query, but certainly can take more time then needed.

Just trying to give some input.

Jason



Ann W. Harrison wrote:

> > Ann W. Harrison wrote:
> >>
> >> ... Academic optimizers are full of little tricks ...
> >> How much code - and execution time - should we
> >>devote that effort?
> >>
> > Jason Dodson wrote:
>
>>Actually, these "little tricks" are what make some RDBMS's worth using.
>
>
> Do you have specific examples? The case that started this was
> WHERE 1 = 0 - a condition that can be evaluated at compile time as
> false. Is it actually worth testing whether both sides of an
> equality can be evaluated at compile time and performing the
> evaluation?
>
>>Maybe a configuration parameter like UseStupidTricks=True/False.
>
>
> The optimizer is complex enough without adding stupid tricks and tests
> for whether they should be used. If you have specific kinds of dumb
> queries you think should be handled, lets consider them case by case.
>
> Regards,
>
>
> Ann