Re: BUG #15869: Custom aggregation returns null when parallelized
От | David Rowley |
---|---|
Тема | Re: BUG #15869: Custom aggregation returns null when parallelized |
Дата | |
Msg-id | CAKJS1f9ckNFoKDz7e5e_bLi-eyD2b+N04jLQSP+fGOte3J3t3g@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #15869: Custom aggregation returns null when parallelized (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #15869: Custom aggregation returns null when parallelized
|
Список | pgsql-bugs |
On Mon, 24 Jun 2019 at 03:32, PG Bug reporting form <noreply@postgresql.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
В списке pgsql-bugs по дате отправления: