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

From Andreas Karlsson
Subject Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
Date
Msg-id b549c8ad-f12e-aad1-9a59-b24cb3e55a17@proxel.se
Whole thread Raw
In response to Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 04/14/2017 11:54 PM, Tom Lane wrote:
> I failed to resist the temptation to poke at this, and found that
> indeed nothing seems to break if we just use one transaction for the
> whole processing of postgres.bki.  So I've pushed a patch that does
> that.  We're definitely down to the point where worrying about the
> speed of bootstrap mode, per se, is useless; the other steps in
> initdb visibly take a lot more time.

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

These four take up about two thirds of the total runtime, so it seems 
likely that we may still have relatively low hanging fruit (but not 
worth committing for PostgreSQL 10).

I have not done profiling of these functions yet, so am not sure how 
they best would be fixed but maybe setup_conversion could be converted 
into bki entries to speed it up.

Andreas



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Different table schema in logical replication crashes
Next
From: Gavin Flower
Date:
Subject: Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)