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