From: | Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: TAP tests take a long time |
Date: | 2017-04-12 06:04:07 |
Message-ID: | CAMsr+YGPu0uNdidcg2NMJ6qmwFYMdyj+p8DCAk=vPu7Eh=umYA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12 April 2017 at 13:27, Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com> wrote:
> On 12 April 2017 at 08:22, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>> On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer
>> <craig(dot)ringer(at)2ndquadrant(dot)com> wrote:
>>> Well, you can get a lot of information on timings in crake's latest
>>> builds for example, or nightjar's.
>>>
>>> Here's an interesting fact: almost all the time taken up in the scripts
>>> test set seems to be consumed in running initdb over and over.
>>>
>>> Is it worth adding an init(cache => 1) option to PostgresNode, where we
>>> stash an initdb'd db in tmp_check/ and just do a simple fs copy of it ?
>>
>> This looks like a good idea to me, but I don't like much the idea of
>> an option in the init() routine as that's hard to maintain.
>
> How so?
>
>> It would
>> make sense to me to be able to override the initialization with an
>> environment variable instead
>
> Yeah, that's reasonable.
>
> Patch attached. It supports setting CACHE_INITDB=0 to disable the cache.
>
> With cache: 3m55.063s (user 7.7s, sys 0m11.833s)
>
> Without cache: 4m11.229s (user 0m16.963s, sys 0m12.384s)
>
> so in a serial run it doesn't make a ton of difference.
>
> Adding some timing on initdb runs shows that initdb takes about 1s, a
> cached copy about 0.1s with our Perl based recursive copy code. So
> it's hardly an overwhelming benefit, but might be more beneficial with
> prove -j .
Of course, it'll need locking for prove -j. Added. Patch attached,
applies on top of prior patch.
With
make PROVE_FLAGS="--timer -j 9" check
I don't see much difference with/without caching initdb results -
saves about 4 seconds, from 74 to 70 seconds, but hard to tell with
the error margins.
So if we're going to do anything, defaulting to parallel prove seems a
good start, and I'm not sure caching initdb results is worth it.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
cache-initdb-tap-locking-v1.patch | text/x-patch | 1.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2017-04-12 06:05:27 | Re: Why does logical replication launcher set application_name? |
Previous Message | Michael Harris | 2017-04-12 05:49:51 | Re: pg_basebackup: Allow use of arbitrary compression program |