Time to run initdb is mostly figure-out-the-timezone work - Mailing list pgsql-hackers

From Tom Lane
Subject Time to run initdb is mostly figure-out-the-timezone work
Date
Msg-id 7611.1261156054@sss.pgh.pa.us
Whole thread Raw
Responses Re: Time to run initdb is mostly figure-out-the-timezone work  (Guillaume Lelarge <guillaume@lelarge.info>)
Re: Time to run initdb is mostly figure-out-the-timezone work  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
On current Fedora 11, there is a huge difference in initdb time if you
have TZ set versus if you don't: I get about 18 seconds versus less than
four.

$ time initdb
... blah blah blah ...

real    0m17.953s
user    0m6.490s
sys     0m10.935s
$ rm -rf $PGDATA
$ export TZ=GMT
$ time initdb
... blah blah blah ...

real    0m3.767s
user    0m2.997s
sys     0m0.784s
$ 

The reason for this is that initdb launches the postmaster many times
(at least 14) and each one of those launches results in a search of
every file in the timezone database, if we don't have a TZ value to
let us identify the timezone immediately.

Now this hardly matters to end users who seldom do initdb, but from a
developer's perspective it would be awfully nice if initdb took less
time.  If other people can reproduce similar behavior, I think it
would be worth the trouble to have initdb forcibly set the TZ or PGTZ
variable while it runs.  AFAIK it does not matter what timezone
environment postgres sees during initdb; we don't put that into the
config file.  It'd be about a one-line addition ...

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Theo Schlossnagle
Date:
Subject: question about implementing XA-ish functions
Next
From: Florian Pflug
Date:
Subject: Re: Update on true serializable techniques in MVCC