Suggestions please: names for function cachability attributes 
Author Message
 Suggestions please: names for function cachability attributes

Since I'm about to have to edit pg_proc.h to add a namespace column,
I thought this would be a good time to revise the current proiscachable
column into the three-way cachability distinction we've discussed
before.  But I need some names for the values, and I'm not satisfied
with the ideas I've had so far.

To refresh people's memory: what we want is to be able to distinguish
between functions that are:

1. Strictly cachable (a/k/a constant-foldable): given fixed input
values, the same result value will always be produced, for ever and
ever, amen.  Examples: addition operator, sin(x).  Given a call
of such a function with all-constant input values, the system is
entitled to fold the function call to a constant on sight.

2. Cachable within a single command: given fixed input values, the
result will not change if the function were to be repeatedly evaluated
within a single SQL command; but the result could change over time.
Examples: now(); datetime-related operations that depend on the current
timezone (or other SET-able variables); any function that looks in
database tables to determine its result.

3. Totally non-cachable: result may change from one call to the next,
even within a single SQL command.  Examples: nextval(), random(),
timeofday().  (Yes, timeofday() and now() are in different categories.
See http://www.***.com/ )

Currently the system can only distinguish cases 1 and 3, so functions
that are really case 2 have to be labeled as case 3; this prevents a lot
of useful optimizations.  In particular, it is safe to use expressions
involving only case-1 and case-2 functions as indexscan conditions,
whereas case-3 functions cannot be optimized into an indexscan.  So this
is an important fix to make.

BTW, because of MVCC semantics, case 2 covers more ground than you might
think.  We are interested in functions whose values cannot change during
a single "scan", ie, while the intra-transaction command counter does
not increment.  So functions that do SELECTs are actually guaranteed to
be case 2, even if stuff outside the function is changing the table
being looked at.

My problem is picking names for the three categories of functions.
Currently we use "with (isCachable)" to identify category 1, but it
seems like this name might actually be more sensible for category 2.
I'm having a hard time picking simple names that convey these meanings
accurately, or even with a reasonable amount of suggestiveness.

Comments, ideas?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.***.com/



Sun, 19 Sep 2004 05:42:02 GMT
 Suggestions please: names for function cachability attributes

My 2 cents.

Level 1. with (isCachableStatic)
Level 2. with (isCachableDynamic)
Level 3. default

In my mind (isCachable) sounds like level 1


Quote:
> Since I'm about to have to edit pg_proc.h to add a namespace column,
> I thought this would be a good time to revise the current proiscachable
> column into the three-way cachability distinction we've discussed
> before.  But I need some names for the values, and I'm not satisfied
> with the ideas I've had so far.

> To refresh people's memory: what we want is to be able to distinguish
> between functions that are:

> 1. Strictly cachable (a/k/a constant-foldable): given fixed input
> values, the same result value will always be produced, for ever and
> ever, amen.  Examples: addition operator, sin(x).  Given a call
> of such a function with all-constant input values, the system is
> entitled to fold the function call to a constant on sight.

> 2. Cachable within a single command: given fixed input values, the
> result will not change if the function were to be repeatedly evaluated
> within a single SQL command; but the result could change over time.
> Examples: now(); datetime-related operations that depend on the current
> timezone (or other SET-able variables); any function that looks in
> database tables to determine its result.

> 3. Totally non-cachable: result may change from one call to the next,
> even within a single SQL command.  Examples: nextval(), random(),
> timeofday().  (Yes, timeofday() and now() are in different categories.
> See
> http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/functions...
>ime.html#FUNCTIONS-DATETIME-CURRENT)

> Currently the system can only distinguish cases 1 and 3, so functions
> that are really case 2 have to be labeled as case 3; this prevents a lot
> of useful optimizations.  In particular, it is safe to use expressions
> involving only case-1 and case-2 functions as indexscan conditions,
> whereas case-3 functions cannot be optimized into an indexscan.  So this
> is an important fix to make.

> BTW, because of MVCC semantics, case 2 covers more ground than you might
> think.  We are interested in functions whose values cannot change during
> a single "scan", ie, while the intra-transaction command counter does
> not increment.  So functions that do SELECTs are actually guaranteed to
> be case 2, even if stuff outside the function is changing the table
> being looked at.

> My problem is picking names for the three categories of functions.
> Currently we use "with (isCachable)" to identify category 1, but it
> seems like this name might actually be more sensible for category 2.
> I'm having a hard time picking simple names that convey these meanings
> accurately, or even with a reasonable amount of suggestiveness.

> Comments, ideas?

>                    regards, tom lane

> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?

> http://www.postgresql.org/users-lounge/docs/faq.html

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly


Sun, 19 Sep 2004 05:55:46 GMT
 Suggestions please: names for function cachability attributes

Quote:
> Since I'm about to have to edit pg_proc.h to add a namespace column,
> I thought this would be a good time to revise the current proiscachable
> column into the three-way cachability distinction we've discussed
> before.  But I need some names for the values, and I'm not satisfied
> with the ideas I've had so far.

Invariant
Cachable
Noncachable

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Sun, 19 Sep 2004 06:47:21 GMT
 Suggestions please: names for function cachability attributes
I am full agreement with proposal. I love it!!

(1) const or constant
(2) cacheable
(3) volatile

P.S.
Tom: My mail doesn't reach you. As an AT&T user, you block my machine's IP
address with the anti-spam blocking. :-(

Quote:

> Since I'm about to have to edit pg_proc.h to add a namespace column,
> I thought this would be a good time to revise the current proiscachable
> column into the three-way cachability distinction we've discussed
> before.  But I need some names for the values, and I'm not satisfied
> with the ideas I've had so far.

> To refresh people's memory: what we want is to be able to distinguish
> between functions that are:

> 1. Strictly cachable (a/k/a constant-foldable): given fixed input
> values, the same result value will always be produced, for ever and
> ever, amen.  Examples: addition operator, sin(x).  Given a call
> of such a function with all-constant input values, the system is
> entitled to fold the function call to a constant on sight.

> 2. Cachable within a single command: given fixed input values, the
> result will not change if the function were to be repeatedly evaluated
> within a single SQL command; but the result could change over time.
> Examples: now(); datetime-related operations that depend on the current
> timezone (or other SET-able variables); any function that looks in
> database tables to determine its result.

> 3. Totally non-cachable: result may change from one call to the next,
> even within a single SQL command.  Examples: nextval(), random(),
> timeofday().  (Yes, timeofday() and now() are in different categories.
> See http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/functions...)

> Currently the system can only distinguish cases 1 and 3, so functions
> that are really case 2 have to be labeled as case 3; this prevents a lot
> of useful optimizations.  In particular, it is safe to use expressions
> involving only case-1 and case-2 functions as indexscan conditions,
> whereas case-3 functions cannot be optimized into an indexscan.  So this
> is an important fix to make.

> BTW, because of MVCC semantics, case 2 covers more ground than you might
> think.  We are interested in functions whose values cannot change during
> a single "scan", ie, while the intra-transaction command counter does
> not increment.  So functions that do SELECTs are actually guaranteed to
> be case 2, even if stuff outside the function is changing the table
> being looked at.

> My problem is picking names for the three categories of functions.
> Currently we use "with (isCachable)" to identify category 1, but it
> seems like this name might actually be more sensible for category 2.
> I'm having a hard time picking simple names that convey these meanings
> accurately, or even with a reasonable amount of suggestiveness.

> Comments, ideas?

>                         regards, tom lane

> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?

> http://www.postgresql.org/users-lounge/docs/faq.html

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly


Mon, 20 Sep 2004 23:32:14 GMT
 
 [ 4 post ] 

 Relevant Pages 

1. Suggestions please: names for function cachability

2. Suggestions please: names for function cachabilityattributes

3. Suggestions please: names for function cachabilityattributes

4. Suggestions please: names for function

5. HELP: ODBC function to return database name and path from DataSoure Name

6. attribute names & typecast/psql default port

7. XML AUTO and attribute names problem

8. Name of databases, tables, attributes and types

9. What is ATTRIBUTE program =name for?

10. Increasing size of attribute names

11. Attribute 'name' not found

12. Problem getting attribute names in OCIAttrGet


 
Powered by phpBB® Forum Software