Re: [HACKERS] TAP tests take a long time

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 while.

Re: [HACKERS] TAP tests take a long time

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 buildfa

Re: [HACKERS] TAP tests take a long time

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 it doesn't look like it woul

Re: [HACKERS] TAP tests take a long time

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 few statements, it seems t

Re: [HACKERS] TAP tests take a long time

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 >>> combined 19m52s of that time. > >> I don't think it's quite fair to complain about

Re: [HACKERS] TAP tests take a long time

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

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, defaulting to parallel prove seems

Re: [HACKERS] TAP tests take a long time

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 timings in crake's latest >>> builds for example, or nightjar's. >>> >>> Here's an interesti

Re: [HACKERS] TAP tests take a long time

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 interesting fact: almost all the time taken up in the scripts >>

Re: [HACKERS] TAP tests take a long time

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 months :-(

Re: [HACKERS] TAP tests take a long time

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 allow it > >> to take -o options to pass to child postgre

Re: [HACKERS] TAP tests take a long time

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 > writes: > >> On Tue, Apr 11, 2017 at 11:32

Re: [HACKERS] TAP tests take a long time

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 we can pass fsync=off . > > That's an idea as well... OK

Re: [HACKERS] TAP tests take a long time

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 in running initdb over and ove

Re: [HACKERS] TAP tests take a long time

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 see takes 33m32s, and the Tap tests take a >>> combined 19m52s of that time. >> I don't

Re: [HACKERS] TAP tests take a long time

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" everywhere (it is supported >>> f

Re: [HACKERS] TAP tests take a long time

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 does nothing much for "

Re: [HACKERS] TAP tests take a long time

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 core, contrib and test_modules) is th

Re: [HACKERS] TAP tests take a long time

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 > get rather jumbled, and I didn't

Re: [HACKERS] TAP tests take a long time

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 don't think it's quite fair to complain about the TAP t

Re: [HACKERS] TAP tests take a long time

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. Es

Re: [HACKERS] TAP tests take a long time

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 the TAP tests taking a > long time to run as a general ma

Re: [HACKERS] TAP tests take a long time

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 > combined 19m52s of that time. That