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  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: using explicit_bzero
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: pg_receivewal documentation