Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers