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

Reply via email to