Re: Constant propagation and similar issues

At 16:37 11/09/00 +0000, Thomas Lockhart wrote:
>> AFAIK hardly anyone actually uses CURRENT, and I've been thinking of
>> proposing that we eliminate it to make the world safe for constant-
>> folding timestamp operations.  (Thomas, any comments here?)
>
>Well, it is a feature from "the old days". Pretty neat one at that, and
>is an example of a useful feature not found in other DBs or in
>standards, but which might show up someday because they are useful.
>Throwing those things away one at a time will end us up at the lowest
>common denominator, eventually :(

Well, Dec RDB has it: the concept of a 'computed by' field. You can define
view-like elements in a table, eg:
 Create Table t1 (    f1 integer,    f2 real,    f12_avg computed by (f1 + f2)/2,    f4 computed by
current_timestamp).

It's actually quite a useful feature, but unlike PGSQL, Dec RDB does not
allow indexes to be created on the fields. Clearly one can just define a
view to get similar results, but it is not as clean.


>Another way of looking at the problem is to ask how we could retain this
>feature in the face of the other optimization "desirements". istm that
>types which have multiple behaviors could be queried for the behavior of
>a particular example by the optimizer. For most types, a "query" would
>not be necessary (so there is minimal overhead), but for this case a
>function could return the property of an example as either cachable or
>not.
>
>Perhaps a true "serial type" would need similar behaviors, as might
>other future types.

This seems like a nice and extensible idea - allowing types to define a
function for testing constancy. At least to allow:
   field < (current_timestamp - interval '1 hour')

to use an index properly.

I guess an alternative would be to define a special 'iscacheable' function:
eg.
  function constant(arg <all-types>) returns <same-type-as-arg>

so we could have:
   field < constant(current_timestamp - interval '1 hour')

although this looks suspiciously like an optimizer hint which I think
people have been opposed to in the past...


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/