Re: Cutting initdb's runtime (Perl question embedded)

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Andreas Karlsson <andreas(at)proxel(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Cutting initdb's runtime (Perl question embedded)
Date: 2017-04-15 02:08:39
Message-ID: bf1defc7-40a5-6e43-0474-c68820b6c9f8@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 15/04/17 13:44, Andreas Karlsson wrote:
> 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
>
>
How much could be done concurrently?

Cheers.
Gavin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2017-04-15 02:47:01 Logical replication - TRAP: FailedAssertion in pgstat.c
Previous Message Andreas Karlsson 2017-04-15 01:44:18 Re: Cutting initdb's runtime (Perl question embedded)