Re: [HACKERS] TAP tests take a long time

2017-04-12 Thread Stephen Frost
Andrew, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > On 04/12/2017 08:40 AM, Andrew Dunstan wrote: > > On 04/12/2017 01:27 AM, Craig Ringer wrote: > >> BTW, I suggest adding --timer to our default PROVE_FLAGS, so we can > >> collect more data from the buildfarm on what takes a

Re: [HACKERS] TAP tests take a long time

2017-04-12 Thread Andrew Dunstan
On 04/12/2017 08:40 AM, Andrew Dunstan wrote: > > On 04/12/2017 01:27 AM, Craig Ringer wrote: >> BTW, I suggest adding --timer to our default PROVE_FLAGS, so we can >> collect more data from the buildfarm on what takes a while. Sample >> output: >> > > I'll add that to the commandline the

Re: [HACKERS] TAP tests take a long time

2017-04-12 Thread Tom Lane
Mithun Cy writes: > I have tried to optimize the tests maintaining the same coverage we were > able to get with it. This patch looks good to me: on my workstation, it reduces the total runtime of the parallel regression tests from ~20.5 to ~16.5 seconds. I concur that

Re: [HACKERS] TAP tests take a long time

2017-04-12 Thread Mithun Cy
On Wed, Apr 12, 2017 at 6:24 PM, Amit Kapila wrote: > > I have looked into the tests and I think we can do some optimization > without losing much on code coverage. First is we are doing both > Vacuum Full and Vacuum on hash_split_heap in the same test after > executing

Re: [HACKERS] TAP tests take a long time

2017-04-12 Thread Amit Kapila
On Tue, Apr 11, 2017 at 9:38 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan >> wrote: >>> This buildfarm run as you can see takes 33m32s, and the Tap tests take a >>>

Re: [HACKERS] TAP tests take a long time

2017-04-12 Thread Andrew Dunstan
On 04/12/2017 01:27 AM, Craig Ringer wrote: > > BTW, I suggest adding --timer to our default PROVE_FLAGS, so we can > collect more data from the buildfarm on what takes a while. Sample > output: > I'll add that to the commandline the buildfarm uses in the upcoming release. cheers andrew --

Re: [HACKERS] TAP tests take a long time

2017-04-12 Thread Tom Lane
Craig Ringer writes: > 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,

Re: [HACKERS] TAP tests take a long time

2017-04-12 Thread Craig Ringer
On 12 April 2017 at 13:27, Craig Ringer wrote: > On 12 April 2017 at 08:22, Michael Paquier wrote: >> On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer >> wrote: >>> Well, you can get a lot of information on

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Craig Ringer
On 12 April 2017 at 08:22, Michael Paquier wrote: > On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer > wrote: >> Well, you can get a lot of information on timings in crake's latest >> builds for example, or nightjar's. >> >> Here's an

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Tom Lane
Andres Freund writes: > The time in initdb is largely spent in regprocin and server start/stop, > so that doesn't surprise me. Yeah. We had a plan for removing the regprocin overhead via preprocessing of the .bki file, but I've not heard anything about that project for

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Andres Freund
On 2017-04-12 10:39:22 +0800, Craig Ringer wrote: > On 12 April 2017 at 08:22, Michael Paquier wrote: > > On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer > > wrote: > >> > >> We should also have a debug --no-fsync option for initdb, or maybe

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Andrew Dunstan
On 04/11/2017 08:12 PM, Craig Ringer wrote: > > > On 12 Apr. 2017 03:14, "Andrew Dunstan" > > wrote: > > > > On 04/11/2017 12:08 PM, Tom Lane wrote: > > Robert Haas

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Craig Ringer
On 12 April 2017 at 08:22, Michael Paquier wrote: > On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer > wrote: >> >> We should also have a debug --no-fsync option for initdb, or maybe allow it >> to take -o options to pass to child postgres so

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Michael Paquier
On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer 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

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Craig Ringer
On 12 Apr. 2017 03:14, "Andrew Dunstan" wrote: On 04/11/2017 12:08 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan >> wrote: >>> This buildfarm run as you can

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Andrew Dunstan
On 04/11/2017 03:58 PM, Andres Freund wrote: > On 2017-04-11 15:52:34 -0400, Tom Lane wrote: >> Andrew Dunstan writes: The other thing that might be useful here is to push on parallelizing buildfarm runs. >>> One reason I haven't supported "make -j nn"

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Tom Lane
Andres Freund writes: > On 2017-04-11 15:52:34 -0400, Tom Lane wrote: >> Agreed, that would be a mess. > Doesn't make's -Otarget largely solve this? Given a sufficiently new make (which would include exactly zero of my own buildfarm critters), that would help. I think it

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Andres Freund
On 2017-04-11 15:52:34 -0400, Tom Lane wrote: > Andrew Dunstan writes: > >> The other thing that might be useful here is to push on parallelizing > >> buildfarm runs. > > > One reason I haven't supported "make -j nn" everywhere (it is supported > > for making

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Tom Lane
Andrew Dunstan writes: >> The other thing that might be useful here is to push on parallelizing >> buildfarm runs. > One reason I haven't supported "make -j nn" everywhere (it is supported > for making core, contrib and test_modules) is that the output tends to >

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Andrew Dunstan
On 04/11/2017 12:08 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan >> wrote: >>> This buildfarm run as you can see takes 33m32s, and the Tap tests take a >>> combined 19m52s of that time. >> I

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Peter Eisentraut
On 4/11/17 12:08, Tom Lane wrote: > The other thing that might be useful here is to push on parallelizing > buildfarm runs. Admittedly that will do nothing for the oldest and > slowest buildfarm critters, but for reasonably modern hardware the > serialization of the tests really handicaps you.

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Tom Lane
Robert Haas writes: > On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan > wrote: >> This buildfarm run as you can see takes 33m32s, and the Tap tests take a >> combined 19m52s of that time. > I don't think it's quite fair to complain about

Re: [HACKERS] TAP tests take a long time

2017-04-11 Thread Robert Haas
On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan wrote: > I've complained about this before. Below are some timings from buildfarm > member nightjar as I test out the new client code. > > This buildfarm run as you can see takes 33m32s, and the Tap tests take a >

[HACKERS] TAP tests take a long time

2017-04-11 Thread Andrew Dunstan
I've complained about this before. Below are some timings from buildfarm member nightjar as I test out the new client code. This buildfarm run as you can see takes 33m32s, and the Tap tests take a combined 19m52s of that time. That seems quite an inordinate amount of time, when checking out the