On Tue, 20 Feb 2024 at 15:16, Tom Lane wrote:
>
> Dean Rasheed writes:
> > Looking at the script itself, the addition, subtraction,
> > multiplication and division tests at the top are probably pointless,
> > since I would expect those operations to be tested adequately (and
> > probably more
Dean Rasheed writes:
> Looking at the script itself, the addition, subtraction,
> multiplication and division tests at the top are probably pointless,
> since I would expect those operations to be tested adequately (and
> probably more thoroughly) by the transcendental test cases. In fact, I
>
> On 20 Feb 2024, at 14:23, Dean Rasheed wrote:
> If we did that, numeric_big would be even further down the list of
> expensive tests, and I'd say it should be run by default.
My motivation for raising this was to get a test which is executed as part of
parallel_schedule to make failures
On Mon, 19 Feb 2024 at 15:35, Tom Lane wrote:
>
> 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
> fo
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 cover
> > On 19 Feb 2024, at 12:48, Tom Lane 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
Daniel Gustafsson writes:
> numeric_big has been left out of parallel_schedule, requiring EXTRA_TESTS to
> run it, since going in back in 1999 (AFAICT it was even the reason EXTRA_TESTS
> was invented). The original commit states that it's huge, and it probably
> was.
> Today it runs faster
numeric_big has been left out of parallel_schedule, requiring EXTRA_TESTS to
run it, since going in back in 1999 (AFAICT it was even the reason EXTRA_TESTS
was invented). The original commit states that it's huge, and it probably was.
Today it runs faster than many tests we have in
