Re: Performance glitch in GetCurrentAbsoluteTime() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Performance glitch in GetCurrentAbsoluteTime()
Date
Msg-id 23183.941733104@sss.pgh.pa.us
Whole thread Raw
In response to Re: Performance glitch in GetCurrentAbsoluteTime()  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List 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 by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] PostgreSQL 6.5.3 built, but not released ...
Next
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] VIEWS, DISTINCT and COUNT