Re: Unwanted expression simplification in PG12b2
От | Darafei "Komяpa" Praliaskouski |
---|---|
Тема | Re: Unwanted expression simplification in PG12b2 |
Дата | |
Msg-id | CAC8Q8tL-T7tSJK-_rw=w-Ukh8eLipnrB_T8MGSPxMbdNtesudg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Unwanted expression simplification in PG12b2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Unwanted expression simplification in PG12b2
|
Список | 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.
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
Support me: http://patreon.com/komzpa
В списке pgsql-hackers по дате отправления: