Re: Teach SELECT DISTINCT first!

From: Paul <>
Date: Wed, 28 Apr 2004 11:21:59 +0100
Message-ID: <UELjc.36980$>

Mikito Harakiri wrote:

>> 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.

If the hint I give is the five actual roots, none of which are integers, a CAS can easily verify this. But what if I incorrectly hint to the engine that there are no integer roots whereas in fact there are? Should the optimizer protect me from my errors? Should I be allowed to choose whether it does or not?

>>> 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.

Yes, I suppose this is driven by economics. If a pure RDBMS was something that would out-perform current DBMSs and was possible to write maybe someone would have done it by now. Though I guess the problem is SQL has become so entrenched in terms of "mindshare" it's difficult to get people to switch.

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

Original text of this message