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
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) |