Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-10 Thread Tom Lane
Noah Misch writes: > On Sat, Apr 09, 2016 at 10:08:01PM -0400, Tom Lane wrote: >> Still, we've reached the most coverage this test can give us at 1000 >> rows, which still means it's wasting the last 99% of its runtime. > If dropping the row count to 1000 shaves >500ms on your

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-10 Thread Alexander Korotkov
On Sun, Apr 10, 2016 at 9:01 AM, Noah Misch wrote: > On Sat, Apr 09, 2016 at 10:08:01PM -0400, Tom Lane wrote: > > I wrote: > > > I was depressed, though not entirely surprised, to find that you get > > > exactly that same line-count coverage if the table size is cut back > >

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-10 Thread Noah Misch
On Sat, Apr 09, 2016 at 10:08:01PM -0400, Tom Lane wrote: > I wrote: > > I was depressed, though not entirely surprised, to find that you get > > exactly that same line-count coverage if the table size is cut back > > to ONE row. > > Oh, I found the flaw in my testing: there are two INSERTs in

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Tom Lane
I wrote: > I was depressed, though not entirely surprised, to find that you get > exactly that same line-count coverage if the table size is cut back > to ONE row. Oh, I found the flaw in my testing: there are two INSERTs in the test script and I was changing only one of them. After correcting

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Tom Lane
Noah Misch writes: > On Sat, Apr 09, 2016 at 11:50:08AM -0400, Tom Lane wrote: >> Would it be possible to dial down the amount of runtime consumed by >> the regression tests for this module? > I find this added test duration reasonable. If someone identifies a way to >

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Peter Geoghegan
On Sat, Apr 9, 2016 at 4:43 PM, Noah Misch wrote: > I find this added test duration reasonable. If someone identifies a way to > realize similar coverage with lower duration, I'd value that contribution. -1 > for meeting some runtime target at the expense of coverage. Older

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Noah Misch
On Sat, Apr 09, 2016 at 11:50:08AM -0400, Tom Lane wrote: > Teodor Sigaev writes: > > Bloom index contrib module > > Would it be possible to dial down the amount of runtime consumed by > the regression tests for this module? > > On my primary dev machine, "make installcheck"

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Tom Lane
I wrote: > Would it be possible to dial down the amount of runtime consumed by > the regression tests for this module? Hmm ... "perf" says that a full 50% of the runtime of contrib/bloom's regression test is consumed by GenericXLogFinish, and of that, the vast majority is consumed by the

Re: [HACKERS] [COMMITTERS] pgsql: Bloom index contrib module

2016-04-09 Thread Tom Lane
Teodor Sigaev writes: > Bloom index contrib module Would it be possible to dial down the amount of runtime consumed by the regression tests for this module? On my primary dev machine, "make installcheck" in contrib/bloom takes 4.5 seconds, which seems a bit excessive when make