Re: Parallel Query

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Luís Roberto Weck <luisroberto(at)siscobra(dot)com(dot)br>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Parallel Query
Date: 2019-11-13 20:40:17
Message-ID: CAMkU=1yuhiG8_V_XEjzLOUz9Vw2eZDoRcHKXXU2bDC1qsR9fgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Nov 13, 2019 at 3:11 PM Luís Roberto Weck <
luisroberto(at)siscobra(dot)com(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tomas Vondra 2019-11-13 20:47:37 Re: Parallel Query
Previous Message Luís Roberto Weck 2019-11-13 20:16:44 Parallel Query