Performance glitch in GetCurrentAbsoluteTime()

I have been doing some profiling this weekend in response to Vadim's
challenge to reduce the amount of overhead in a simple INSERT command.
I've found a number of simple improvements that I hope to check in
shortly.  I came across something in the time code that I thought I'd
better check with you before changing.

In utils/adt/nabstime.c, the function GetCurrentAbsoluteTime() is called
during each StartTransaction in order to save the transaction's start
time.  It shows up unreasonably high in my profile (> 1% of runtime):
               0.62   10.22  100001/100001      StartTransaction [65]
[91]     1.4    0.62   10.22  100001         GetCurrentAbsoluteTime [91]               0.92    8.30  100001/100001
localtime[105]               0.88    0.00  100001/100004      time [305]               0.12    0.00  100001/104713
strcpy[479]
 

Now the interesting thing about this is that the essential part of the
function is just the time() call, AFAICS, and that's quite cheap.  More
than 90% of the runtime is being spent in the "if (!HasCTZSet)" branch.
I see no reason for that code to be run during every single transaction.
It sets the following variables:
CTimeZoneCDayLightCTZName

CDayLight is not used *anywhere* except for debug printouts, and could
go away completely.  CTZName is not used if USE_POSIX_TIME is defined,
which is true on most platforms.  CTimeZone is not quite as useless, but
there are only a couple places where it's used when USE_POSIX_TIME is
true, and they don't look like critical-path stuff to me.

We could almost say that these variables need only be set once per
backend startup, but I suppose that would do the wrong thing in a
backend that's left running over a daylight-savings transition.

What I'm inclined to do is arrange for these variables to be calculated
only on-demand, at most once per transaction.  It'd be even nicer to
get rid of them entirely, but I don't think I understand the time code
well enough to venture that.

Do you have any comments pro or con on this?
        regards, tom lane