Re: Load TIME fields - proposed performance improvement - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Load TIME fields - proposed performance improvement
Date
Msg-id 1135223.1600740765@sss.pgh.pa.us
Whole thread Raw
In response to Load TIME fields - proposed performance improvement  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Load TIME fields - proposed performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Peter Smith <smithpb2250@gmail.com> writes:
> IIUC the code is calling GetCurrentDateTime only to acquire the
> current TX timestamp as a struct pg_tm in order to derive some
> timezone information.
> ...
> I have attached a patch which caches this struct, so now those 225
> million calls are reduced to just 1 call.

Interesting idea, but this implementation is leaving a *lot*
on the table.  If we want to cache the result of
timestamp2tm applied to GetCurrentTransactionStartTimestamp(),
there are half a dozen different call sites that could make
use of such a cache, eg, GetSQLCurrentDate and GetSQLCurrentTime.
Applying the caching only in one indirect caller of that seems
pretty narrow-minded.

I'm also strongly suspecting that this implementation is outright
broken, since it's trying to make DecodeTimeOnly's local variable
"tt" into cache storage ... but that variable could be overwritten
with other values, during calls that take the other code path there.
The cache ought to be inside GetCurrentDateTime or something it
calls, and the value needs to be copied to the given output variable.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Load TIME fields - proposed performance improvement
Next
From: Tom Lane
Date:
Subject: Re: Load TIME fields - proposed performance improvement