Re: [COMMITTERS] pgsql: Bloom index contrib module - Mailing list pgsql-hackers

From Noah Misch
Subject Re: [COMMITTERS] pgsql: Bloom index contrib module
Date
Msg-id 20160410060102.GC1741844@tornado.leadboat.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Bloom index contrib module  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Bloom index contrib module  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Re: [COMMITTERS] pgsql: Bloom index contrib module  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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 the test
> script and I was changing only one of them.  After correcting that,
> the results behave a little more sanely:
> 
>                Line Coverage           Functions
> 1 row:         70.4 %    349 / 496    93.1 %    27 / 29
> 10 row:        73.6 %    365 / 496    93.1 %    27 / 29
> 100 rows:      73.6 %    365 / 496    93.1 %    27 / 29
> 1000 rows:     75.4 %    374 / 496    93.1 %    27 / 29
> 
> 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 primary machine, +1
for committing such a row count change.  This is exactly what I meant by
"someone identifies a way to realize similar coverage with lower duration."
Thanks for contributing this study.



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Move PinBuffer and UnpinBuffer to atomics
Next
From: Alexander Korotkov
Date:
Subject: Re: Move PinBuffer and UnpinBuffer to atomics