Re: Performance glitch in GetCurrentAbsoluteTime()

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)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