Time to run initdb is mostly figure-out-the-timezone work

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Time to run initdb is mostly figure-out-the-timezone work
Date: 2009-12-18 17:07:34
Message-ID: 7611.1261156054@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2009-12-18 17:15:20 Re: Update on true serializable techniques in MVCC
Previous Message Theo Schlossnagle 2009-12-18 17:05:37 question about implementing XA-ish functions