Re: Performance glitch in GetCurrentAbsoluteTime()
| От | Tom Lane |
|---|---|
| Тема | Re: Performance glitch in GetCurrentAbsoluteTime() |
| Дата | |
| Msg-id | 23183.941733104@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Performance glitch in GetCurrentAbsoluteTime() (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
| Список | pgsql-hackers |
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> (back online after a week of downtime)
I was wondering why you were so quiet. Hardware trouble?
>> What I'm inclined to do is arrange for these variables to be calculated
>> only on-demand, at most once per transaction.
> At most once per transaction is what I was hoping the behavior already
> is.
Actually, my gripe is that it's done in every transaction whether
needed or not...
> Anyway, if we can take the time() result and *later* figure out
> the other values, then we could:
> 1) clear a flag when time() is called
> 2) use a wrapper around a stripped GetCurrentAbsoluteTime() for
> date/time support
> 3) if the flag in (1) is clear, then evaluate the other parameters
Right, that was pretty much what I was thinking too. As long as
CTimeZone &etc are evaluated using the time value saved at the
start of the transaction, the behavior will be the same.
regards, tom lane
В списке pgsql-hackers по дате отправления: