=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= <me@komzpa.net> writes:
> Many thanks for the parallel improvements in Postgres 12. Here is one of
> cases where a costy function gets moved from a parallel worker into main
> one, rendering spatial processing single core once again on some queries.
> Perhaps an assumption "expressions should be mashed together as much as
> possible" should be reviewed and something along "biggest part of
> expression should be pushed down into parallel worker"?
I don't see anything in your test case that proves what you think it does.
The expensive calculation *is* being done in the worker in the first
example. It's not real clear to me why the first example is only choosing
to use one worker rather than 3, but probably with a larger test case
(ie bigger table) that decision would change.
Just to clarify --- when you see something like this:
> │ Gather (cost=159.86..42668.93 rows=200 width=36)
> │ Output: (st_collect(st_difference(postgis_test_table.a,st_unaryunion(postgis_test_table.b)))),
postgis_test_table.id
> │ -> GroupAggregate (cost=59.86..42568.73 rows=200 width=36)
> │ Output: st_collect(st_difference(postgis_test_table.a,st_unaryunion(postgis_test_table.b))),
postgis_test_table.id
EXPLAIN is trying to tell you that the expression value is being
computed by the lower plan node, and just passed up to the upper
plan node --- that's what the extra parens in the upper expression
printout mean. Perhaps there's some way to make that clearer,
but I haven't thought of one that doesn't seem very clutter-y.
regards, tom lane
