|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, John Naylor <jcnaylor(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andreas Karlsson <andreas(at)proxel(dot)se>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)|
|Views:||Raw Message | Whole Thread | Download mbox|
> ... I'll
> take a look at whipping up something that checks /etc/localtime.
Here's a draft patch. It seems to do what I expect on a couple of
different macOS releases as well as recent Fedora. Googling finds
some suggestions that there might be other locations for the symlink,
for instance it's alleged that glibc can be configured to look at
/usr/local/etc/localtime instead of /etc/localtime. But AFAICS none
of the alternative locations are used on enough systems that it'd be
worth the cycles to check them. Likewise, there seem to be some
systems with conventions about storing the zone name in a text file
someplace, but not really enough of them to make it worth our time
to support that.
The initdb speedup on the other boxes I checked seems to be in the
vicinity of 50 ms out of circa-1-sec total, which is less than I'd have
expected from my measurements on my RHEL6 box :-(. Still, I think it's
worth doing, not least because (if it works) this fixes the problem that
you may get an unexpected alias for your system timezone, as in this
complaint awhile back:
I also changed initdb so that it reports what zone name it picked.
I have a vague recollection that it might've done that long ago, and
we suppressed it in a burst of enthusiasm about making initdb less
chatty. That seems like something to undo, since we're tweaking what
are still basically heuristic rules for choosing the zone.
Next question is what to do with this. Do we want to sit on it till
v12, or sneak it in now?
regards, tom lane
|Next Message||David G. Johnston||2018-05-10 16:50:25||Re: Should we add GUCs to allow partition pruning to be disabled?|
|Previous Message||Alvaro Herrera||2018-05-10 15:57:25||Re: Should we add GUCs to allow partition pruning to be disabled?|