From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | kdorsel(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15869: Custom aggregation returns null when parallelized |
Date: | 2019-06-24 02:51:19 |
Message-ID: | CAKJS1f9ckNFoKDz7e5e_bLi-eyD2b+N04jLQSP+fGOte3J3t3g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, 24 Jun 2019 at 03:32, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> Here's the setup code:
> --CREATE TABLE temp (val double precision);
> --insert into temp (val) select i from generate_series(0, 150000) as t(i);
> --set force_parallel_mode = on;
> select (stats_agg(val)).* from temp;
I don't think force_parallel_mode does what you think it does. It just
adds a Gather node to the top of the plan, if the plan is deemed
parallel safe. It's not going to force your aggregate to be
parallelised.
You might coax the planner into generating a parallel aggregate plan
by setting parallel_tuple_cost and parallel_setup_cost both to 0.
> Expected results:
> 150001, 37500, 75000, 112500
>
> Results when run in parallel:
> 150001, null, null, null
Are you actually getting a partial and finalize aggregate node with
that? Can you show the EXPLAIN output of each?
You might also want to double check your combine function. It does not
look like it's very well coded to handle NULL values for arrays that
have yet to receive their fill of 5 elements.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2019-06-24 11:06:05 | Re: Querying foreign table with SP-GiST index results in “ERROR: cache lookup failed for type 0” |
Previous Message | Michael Paquier | 2019-06-24 02:17:28 | Re: Function pg_database_size fails with "Permission denied" on a corrupted fsm file |