Re: Parallel Query

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Parallel Query
Дата
Msg-id CAMkU=1yuhiG8_V_XEjzLOUz9Vw2eZDoRcHKXXU2bDC1qsR9fgg@mail.gmail.com
обсуждение исходный текст
Ответ на Parallel Query  (Luís Roberto Weck <luisroberto@siscobra.com.br>)
Ответы Re: Parallel Query  (Luís Roberto Weck <luisroberto@siscobra.com.br>)
Список pgsql-performance
On Wed, Nov 13, 2019 at 3:11 PM Luís Roberto Weck <luisroberto@siscobra.com.br> wrote:
Hi!

Is there a reason query 3 can't use parallel workers? Using q1 and q2
they seem very similar but can use up to 4 workers to run faster:

q1: https://pastebin.com/ufkbSmfB
q2: https://pastebin.com/Yt32zRNX
q3: https://pastebin.com/dqh7yKPb

The sort node on q3 takes almost 12 seconds, making the query run on 68 
if I had set enough work_mem to make it all in memory.

The third one thinks it is going find 3454539 output rows.  If it run in parallel, it thinks it will be passing lots of rows up from the parallel workers, and charges a high price (parallel_tuple_cost = 0.1) for doing so.  So you can try lowering  parallel_tuple_cost, or figuring out why the estimate is so bad.

Cheers,

Jeff

В списке pgsql-performance по дате отправления:

Предыдущее
От: Luís Roberto Weck
Дата:
Сообщение: Parallel Query
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Parallel Query