Re: [HACKERS] Cutting initdb's runtime (Perl question embedded) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Date
Msg-id 5807.1492229253@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
List pgsql-hackers
Andreas Karlsson <andreas@proxel.se> writes:
> Looked some at this and what take time now for me seems to mainly be 
> these four things (out of a total runtime of 560 ms).

> 1. setup_conversion:        140 ms
> 2. select_default_timezone:  90 ms
> 3. bootstrap_template1:      80 ms
> 4. setup_schema:             65 ms

FWIW, you can bypass select_default_timezone by setting environment
variable TZ to a valid timezone name before calling initdb.  On
my workstation, that currently cuts the time for "initdb --no-sync"
from about 1.25 sec to just about exactly 1.0 sec.

I doubt that we want all the buildfarm members to switch over to
doing that, since then we'd lose coverage of select_default_timezone.
But it's interesting to speculate about having the buildfarm script
extract the selected timezone name out of postgresql.conf after the
first initdb it does, and then set TZ for remaining tests.  We surely
don't need to test select_default_timezone more than once per
buildfarm run.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [HACKERS] [pgsql-www] Small issue in online devel documentation build
Next
From: Pavan Deolasee
Date:
Subject: Re: [HACKERS] PANIC in pg_commit_ts slru after crashes