From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | thomas(at)pgsql(dot)com |
Cc: | PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: iscacheable for date/time? |
Date: | 2001-09-26 14:57:58 |
Message-ID: | 840.1001516278@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lockhart <lockhart(at)fourpalms(dot)org> writes:
> Can anyone recall why the interval data type would have been
> considered non-cacheable?
I believe I made all functions for all datetime-related types
noncacheable, simply because I wasn't sure which of them had the
"current" behavior.
> For timestamp and timestamptz, I've eliminated the "current" special
> value which afaicr is the only reason timestamp had not been cacheable
> in the past. Are there any functions which should *not* be considered
> cacheable for those types? Apparently the _in() and _out() functions
> should not be?
in() should not be, since its result for the strings "now", "today",
"tomorrow", etc is variable. But AFAICS there's no reason to mark out()
as noncacheable anymore.
The general rule is: if there are any fixed input values for which the
output might vary over time, then it should be noncachable.
Dunno why to_char is marked noncachable; does it perhaps have
format-string entries that pick up current time somehow? I might just
have been worried about its response to "current", though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-09-26 15:01:22 | Re: iscacheable for date/time? |
Previous Message | Bruce Momjian | 2001-09-26 14:54:37 | Re: PERFORMANCE IMPROVEMENT by mapping WAL FILES |