# Re: Teach SELECT DISTINCT first!

Date: Wed, 28 Apr 2004 11:21:59 +0100

Message-ID: <UELjc.36980$Y%6.5047943_at_wards.force9.net>

>> I'm sure you could expand it out in terms of arithmetic operations >> and elementary functions. It might be very long though...

*>*

> No, you would need quantifiers.

OK so we exclude all expressions that have "for all" or "there exists" quantifying over some variable? What are we classing as elementary functions, does it include things like trigonometric functions and exponentiation?

Suppose I say "SELECT * FROM R WHERE i^4 + j^4 = k^4" where i,j,k are integer columns?

Consider a function f that is a polynomial expression of order 5.
Suppose it has no integer roots, and I know this.
This is a simple arithmetic function.

Now if I do "SELECT * FROM R WHERE f(i) = 0"
Galois theory tells us there is no formula to tell us roots of a quintic
equation, so a CAS can't help here. But if I could hint to the query
engine it would be useful in this case.

>>> CAS have their own problems even within practical realm of >>> closed-form expressions, there is no need to go as far as FLT. >>> The idea is however, that in vast majority of the cases CAS does >>> an excellent work.

As does heuristics and finite precision maybe?

>> OK so say for example I do "SELECT i from R WHERE i*i < 0" where i >> is an integer column, then the DBMS engine should know that the >> square of an integer is never less than zero?

*>*

> Is it really different from today's RDBMS primitive predicate

*> deduction capabilities when optimizer derives*

*>*

*> x = 5 from x = y and y = 5 ?*

No it's not, I'm agreeing with you here, perhaps I didn't phrase it very well.

>> Yes, I guess the problem is it's very complicated to write just a >> plain DBMS, let alone one with fancy optimizations, unlimited >> precision and computer algebra systems etc. built in.

*>*

> But, you know what? Writing clean RDBMS engine is not even on

*> vendor's priority list. They are extremely busy chasing X, G and*

*> other fads.*

Paul. Received on Wed Apr 28 2004 - 12:21:59 CEST