On 22 June 2018 at 00:18, Rajkumar Raghuwanshi <rajkumar.raghuwan...@enterprisedb.com> wrote: > CREATE TABLE part (c1 INT,c2 INT) PARTITION BY RANGE (c1); > CREATE TABLE part_p1 PARTITION OF part FOR VALUES FROM (1) TO (3); > CREATE TABLE part_p2 PARTITION OF part FOR VALUES FROM (3) TO (5); > > INSERT INTO part VALUES (1,5),(2,15),(3,3),(4,17); > > postgres=# SET parallel_setup_cost=0; > postgres=# SELECT COUNT(c1),STDDEV(c2),VARIANCE(c2) FROM part; > count | stddev | variance > -------+--------+---------- > 4 | 0 | 0 > (1 row)
Well, that's quite surprising. It appears to be a bug in numeric_poly_combine for machines without a working int128 type. The parameters in accum_sum_copy are in the incorrect order. The very minimal fix is attached, but I'll need to go look at where the tests for this have gone. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
fix_numeric_poly_combine.patch
Description: Binary data
