On Sun, Apr 10, 2016 at 9:01 AM, Noah Misch <n...@leadboat.com> wrote:
> 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. +1, row count reduction is a good to reduce regression test time. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
