From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Andreas Karlsson <andreas@proxel.se>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: Cutting initdb's runtime (Perl question embedded)
Date: Thu, 13 Apr 2017 14:05:43 -0400
Message-ID: <9244.1492106743@sss.pgh.pa.us> (raw)
In-Reply-To: <20170413170614.6pv2mpqiq7s6huio@alap3.anarazel.de>
References: <30896.1492006367@sss.pgh.pa.us>
<a15e94ac-c346-5816-69ae-ec6811e32af1@proxel.se>
<972d541d-7285-53ff-ea71-dcbfd886570a@proxel.se>
<6312.1492100010@sss.pgh.pa.us>
<20170413164132.3nhobp4z4wnnvhca@alap3.anarazel.de>
<27409.1492102574@sss.pgh.pa.us>
<20170413170614.6pv2mpqiq7s6huio@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andres Freund <andres@anarazel.de> writes:
> On 2017-04-13 12:56:14 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> Cool. I wonder if we also should remove AtEOXact_CatCache()'s
>>> cross-checks - the resowner replacement has been in place for a while,
>>> and seems robust enough. They're now the biggest user of time.
>> Hm, biggest user of time in what workload? I've not noticed that
>> function particularly.
> Just initdb. I presume it's because the catcaches will frequently be
> relatively big there.
Hm. That ties into something I was looking at yesterday. The only
reason that function is called so much is that bootstrap mode runs a
separate transaction for *each line of the bki file* (cf do_start,
do_end in bootparse.y). Which seems pretty silly. I experimented
with collapsing all the transactions for consecutive DATA lines into
one transaction, but couldn't immediately make it work due to memory
management issues. I didn't try collapsing the entire run into a
single transaction, but maybe that would actually be easier, though
no doubt more wasteful of memory.
>> I agree that it doesn't seem like we need to spend a lot of time
>> cross-checking there, though. Maybe keep the code but #ifdef it
>> under some nondefault debugging symbol.
> Hm, if we want to keep it, maybe tie it to CLOBBER_CACHE_ALWAYS or such,
> so it gets compiled at least sometimes? Not a great fit, but ...
Don't like that, because CCA is by definition not the normal cache
behavior. It would make a bit of sense to tie it to CACHEDEBUG,
but as you say, it'd never get tested normally if we do that.
On the whole, though, we may be looking at diminishing returns here.
I just did some "perf" measurement of the overall "initdb" cycle,
and what I'm seeing suggests that bootstrap mode as such is now a
pretty small fraction of the overall cycle:
+ 51.07% 0.01% 28 postgres postgres [.] PostgresMain #
...
+ 13.52% 0.00% 0 postgres postgres [.] AuxiliaryProcessMain #
That says that the post-bootstrap steps are now the bulk of the time,
which agrees with naked-eye observation.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, andreas@proxel.se
Subject: Re: Cutting initdb's runtime (Perl question embedded)
In-Reply-To: <9244.1492106743@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox