Re: Constant propagation and similar issues

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jules Bean <jules(at)jellybean(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Constant propagation and similar issues
Date: 2000-09-18 09:05:18
Message-ID: 3.0.5.32.20000918190518.029d53e0@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message devik 2000-09-18 09:31:30 WAL & MVCC
Previous Message Peter Eisentraut 2000-09-18 08:56:13 Re: broken locale in 7.0.2 without multibyte support (FreeBSD 4.1-RELEASE) ?