Re: Functional index problems. (Was: Many joins: monthly summaries S-L--O--W) - Mailing list pgsql-novice

From Michael Glaesmann
Subject Re: Functional index problems. (Was: Many joins: monthly summaries S-L--O--W)
Date
Msg-id 704FD876-04F0-11D8-81AE-0005029FC1A7@myrealbox.com
Whole thread Raw
In response to Re: Functional index problems. (Was: Many joins: monthly summaries S-L--O--W)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Functional index problems. (Was: Many joins: monthly summaries S-L--O--W)
List pgsql-novice
On Thursday, Oct 23, 2003, at 04:17 Asia/Tokyo, Tom Lane wrote:

<excerpt>I'm not particularly happy with the phrase "expressional
index", and

would like to think of something else to use before the 7.4 docs go

final.  Any ideas?

</excerpt>

Though it might be nice to be creative and name it something like
"Bill", for a defined language like SQL I think it's best to work
within the framework already used to describe the language. Looking in
the PostgreSQL docs (which I'm sure you've done), I find this
definition of "value expression"


<fontfamily><param>Lucida Grande</param><bigger>A value expression is
one of the following:

- A constant or literal value; see
<color><param>0000,0000,6666</param>Section 1.1.2 </color>.

- A column reference.

- A positional parameter reference, in the body of a function
declaration.

- An operator invocation.

- A function call.

- An aggregate expression.

- A type cast.

- A scalar subquery.

- Another value expression in parentheses, useful to group
subexpressions and override precedence.


Preceding this is a paragraph mentioning that value expressions are
also called "scalar expressions" or just "expressions". I was
surprised to find column references are included in this list, but
thinking about it, a column has a scalar value, which is what any
function or operator returns as well. According to the above
description of "value expression", a normal column index is just a
special case of the more general "expression" index.


(Actually, I'm a bit confused with the definition of value expression.
Does column reference here mean value in the same row (and same
table)? That's the only way I can see getting a scalar value. If it
means reference in the constraint meaning, it's a set of allowed
values, rather than a specific one, which definitely wouldn't work for
an index. Perhaps the use of the word "reference" here is
inappropriate, though I haven't looked through the rest of the
documentation to see how the term "column reference" is used. My bad,
I know. I'll definitely accept criticism for not doing my homework
thoroughly.)


To me, an operator is just a special class of function that doesn't
use the more general func(arg [, arg]) construction. 2 + 2 could just
as easily be add(2,2) — and maybe it is already defined this way as
well. I haven't checked.


However, I can see that it might be useful to distinguish between
functions and column references. One term I thought about was "derived
index". Another was "evaluated index". But both of these terms seem to
introduce unnecessary language.


My final thought would be to continue using "functional index", noting
that operators are a special class of function. Out of the above
description of "value expression", I believe only functions and
operators are allowed as expressions in the CREATE INDEX syntax,
correct? (Besides referring to a column.)


What do you think?


Michael</bigger></fontfamily>On Thursday, Oct 23, 2003, at 04:17 Asia/Tokyo, Tom Lane wrote:
> I'm not particularly happy with the phrase "expressional index", and
> would like to think of something else to use before the 7.4 docs go
> final.  Any ideas?

Though it might be nice to be creative and name it something like
"Bill", for a defined language like SQL I think it's best to work
within the framework already used to describe the language. Looking in
the PostgreSQL docs (which I'm sure you've done), I find this
definition of "value expression"

A value expression is one of the following:
- A constant or literal value; see Section 1.1.2 .
- A column reference.
- A positional parameter reference, in the body of a function
declaration.
- An operator invocation.
- A function call.
- An aggregate expression.
- A type cast.
- A scalar subquery.
- Another value expression in parentheses, useful to group
subexpressions and override precedence.

Preceding this is a paragraph mentioning that value expressions are
also called "scalar expressions" or just "expressions". I was surprised
to find column references are included in this list, but thinking about
it, a column has a scalar value, which is what any function or operator
returns as well. According to the above description of "value
expression", a normal column index is just a special case of the more
general "expression" index.

(Actually, I'm a bit confused with the definition of value expression.
Does column reference here mean value in the same row (and same table)?
That's the only way I can see getting a scalar value. If it means
reference in the constraint meaning, it's a set of allowed values,
rather than a specific one, which definitely wouldn't work for an
index. Perhaps the use of the word "reference" here is inappropriate,
though I haven't looked through the rest of the documentation to see
how the term "column reference" is used. My bad, I know. I'll
definitely accept criticism for not doing my homework thoroughly.)

To me, an operator is just a special class of function that doesn't use
the more general func(arg [, arg]) construction. 2 + 2 could just as
easily be add(2,2) — and maybe it is already defined this way as well.
I haven't checked.

However, I can see that it might be useful to distinguish between
functions and column references. One term I thought about was "derived
index". Another was "evaluated index". But both of these terms seem to
introduce unnecessary language.

My final thought would be to continue using "functional index", noting
that operators are a special class of function. Out of the above
description of "value expression", I believe only functions and
operators are allowed as expressions in the CREATE INDEX syntax,
correct? (Besides referring to a column.)

What do you think?

Michael

pgsql-novice by date:

Previous
From: Tom Lane
Date:
Subject: Re: advice
Next
From: Tom Lane
Date:
Subject: Re: Functional index problems. (Was: Many joins: monthly summaries S-L--O--W)