Re: iscacheable for date/time?

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

In response to

Browse pgsql-hackers by date

  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