From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Wang Mike <itlist(at)msn(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: clock_timestamp() and transaction_timestamp() function |
Date: | 2003-12-01 15:34:04 |
Message-ID: | 22492.1070292844@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> It would be very useful if we had a parameter that controlled whether
> current_timestamp maps to statement_timestamp or to transaction_timestamp.
This is a nonstarter, as is the previous proposal to have a single
function with an explicit parameter that selects the behavior. The
reason is that any such function would have to be treated as completely
non-optimizable. It's really important that current_timestamp be STABLE
so that queries like
where entrytimestamp >= current_timestamp - '10 minutes'
can use an index. This means you can't have options that make it not
be STABLE.
> The name "clock_timestamp" seems kind of unfortunate.
Agreed, it's not the best choice.
> Why is this functionality needed anyway?
Performance measurements within plpgsql functions, for example.
I am unconvinced that anyone has really proven the need for
statement_timestamp, but a cleaner replacement for timeofday()
would be nice to have.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-12-01 15:36:51 | Re: clock_timestamp() and transaction_timestamp() function |
Previous Message | Bruce Momjian | 2003-12-01 14:45:44 | Re: clock_timestamp() and transaction_timestamp() function |