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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: