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

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: 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 01:44:18
Message-ID: b549c8ad-f12e-aad1-9a59-b24cb3e55a17@proxel.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Flower 2017-04-15 02:08:39 Re: Cutting initdb's runtime (Perl question embedded)
Previous Message Petr Jelinek 2017-04-15 01:36:18 Re: Different table schema in logical replication crashes