Re: Unwanted expression simplification in PG12b2 - Mailing list pgsql-hackers

From Darafei "Komяpa" Praliaskouski
Subject Re: Unwanted expression simplification in PG12b2
Date
Msg-id CAC8Q8tL-T7tSJK-_rw=w-Ukh8eLipnrB_T8MGSPxMbdNtesudg@mail.gmail.com
Whole thread Raw
In response to Re: Unwanted expression simplification in PG12b2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Unwanted expression simplification in PG12b2  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On Wed, Jul 17, 2019 at 11:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Darafei "Komяpa" 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.

Indeed, it seems I failed to minimize my example.

Here is the actual one, on 90GB table with 16M rows:
https://gist.github.com/Komzpa/8d5b9008ad60f9ccc62423c256e78b4c

I can share the table on request if needed, but hope that plan may be enough.

--
Darafei Praliaskouski

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: using explicit_bzero
Next
From: Laurenz Albe
Date:
Subject: Re: pg_receivewal documentation