Re: [COMMITTERS] pgsql: Bloom index contrib module

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Bloom index contrib module
Date: 2016-04-10 17:17:13
Message-ID: 20117.1460308633@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> 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 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.

Further testing with gcov showed that the max coverage point was reached
somewhere between 500 and 750 rows (I didn't bother to pin it down
exactly). So I thought setting the table size to 1000 rows was probably
shaving things a bit too close; I made it 2000 rows instead.

I also added a few more test cases to improve the coverage beyond what
it was to start with, using a white-box approach of modifying the test
script until gcov said that it was hitting the areas it wasn't before.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Stephen Frost 2016-04-10 17:42:59 Regression test CREATE USER/ROLE usage
Previous Message Tom Lane 2016-04-10 17:12:35 pgsql: Improve contrib/bloom regression test using code coverage info.

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2016-04-10 17:42:59 Regression test CREATE USER/ROLE usage
Previous Message Pavel Stehule 2016-04-10 17:01:50 Re: Relax requirement for INTO with SELECT in pl/pgsql