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

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Bloom index contrib module
Date
Msg-id 20117.1460308633@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Bloom index contrib module  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.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



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Relax requirement for INTO with SELECT in pl/pgsql
Next
From: Stephen Frost
Date:
Subject: Regression test CREATE USER/ROLE usage