From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: partition table and stddev() /variance() behaviour |
Date: | 2018-06-22 03:08:51 |
Message-ID: | CAKJS1f_3=0WNv-aOE0N3AUfiGnJt8qM9u7RY4iSXG7_ep_JmZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22 June 2018 at 03:30, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
okay. My sniper rifle was locked away for the evening. I decided it
was best to sleep before any careful aiming was required.
I see you've done the deed already. Thanks.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | shao bret | 2018-06-22 03:45:01 | Incorrect comments in commit_ts.c |
Previous Message | Hubert Zhang | 2018-06-22 02:11:26 | Re: Considering signal handling in plpython again |