Re: numeric_big in make check?

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On 19 Feb 2024, at 12:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Or we could just flush it. It's never detected a bug, and I think
>> you'd find that it adds zero code coverage (or if not, we could
>> fix that in a far more surgical and less expensive manner).

> Off the top of my head, I can't say to what extent that's true, but it
> wouldn't surprise me if at least some of the tests added in the last 4
> commits to touch that file aren't covered by tests elsewhere. Indeed
> that certainly looks like the case for 18a02ad2a5. I'm sure those
> tests could be pared down though.

I thought I'd try to acquire some actual facts here, so I compared
the code coverage shown by "make check" as of HEAD, versus "make
check" after adding numeric_big to parallel_schedule. I saw the
following lines of numeric.c as being covered in the second run
and not the first:

numeric():
1285 || !NUMERIC_IS_SHORT(num)))
1293 new->choice.n_long.n_sign_dscale = NUMERIC_SIGN(new) |
1294 ((uint16) dscale & NUMERIC_DSCALE_MASK);
div_var_fast():
9185 idivisor = idivisor * NBASE + var2->digits[1];
9186 idivisor_weight--;
sqrt_var():
10073 res_ndigits = res_weight + 1 - (-rscale - 1) / DEC_DIGITS;

Pretty poor return on investment for the runtime consumed. I don't
object to adding something to numeric.sql that's targeted at adding
coverage for these (or anyplace else that's not covered), but let's
not just throw cycles at the problem.

Oddly, there were a few lines in numeric_poly_combine and
int8_avg_combine that were hit in the first run and not the second.
Apparently our tests of parallel aggregation aren't as reproducible as
one could wish.

regards, tom lane