Re: partition table and stddev() /variance() behaviour

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> On 22 June 2018 at 02:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> coverage.postgresql.org shows that numeric_poly_serialize/combine()
>> aren't exercised at all by the regression tests. Which is embarrassing
>> for this case, but I'm a bit leery of trying to insist on 100% coverage.
>> It might be a plan to insist on buildfarm coverage for anything with
>> platform-varying code in it, in which case there's at least one
>> other undertested bit of HAVE_INT128 code in numeric.c.

> I think some coverage of the numerical aggregates is a good idea, so
> I've added some in the attached. I managed to get a parallel plan
> going with a query to onek, which is pretty cheap to execute. I didn't
> touch the bool aggregates. Maybe I should have done that too..?

This sort of blunderbuss testing was exactly what I *didn't* want to do.
Not only is this adding about 20x as many cycles as we need (at least for
this specific numeric_poly_combine issue), but I'm quite afraid that the
float4 and/or float8 cases will show low-order-digit irreproducibility
in the buildfarm. I think we should look at the coverage report for the
files in question and add targeted tests to cover gaps where there's
platform-varying code, such that the buildfarm might expose problems
that were missed by the code's author.

regards, tom lane