Em 13/11/2019 19:08, Jeff Janes escreveu:
On Wed, Nov 13, 2019 at 3:59 PM Luís Roberto Weck
mailto:luisrobe...@siscobra.com.br>> wrote:
Indeed, reducing the costs made the query run in parallel, but the
improvement in speed was not worth the cost (CPU).
Could you show the plan for t
On Wed, Nov 13, 2019 at 4:01 PM Luís Roberto Weck <
luisrobe...@siscobra.com.br> wrote:
>
> Maybe PostgreSQL can't find a way to calculate having estimates?
>
I wasn't even thinking of the HAVING estimates I was thinking of just the
raw aggregates. It can't implement the HAVING until has the raw
On Wed, Nov 13, 2019 at 3:59 PM Luís Roberto Weck <
luisrobe...@siscobra.com.br> wrote:
>
>
> Indeed, reducing the costs made the query run in parallel, but the
> improvement in speed was not worth the cost (CPU).
>
Could you show the plan for that?
Em 13/11/2019 17:40, Jeff Janes escreveu:
On Wed, Nov 13, 2019 at 3:11 PM Luís Roberto Weck
mailto:luisrobe...@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:
t's likely cheaper to just do everything
in a single process serially.
How does the explain analyze output look like without the HAVING clause?
Try setting parallel_setup_cost and parallel_tuple_cost to 0. That might
trigger parallel query.
regards
Tomas,
EXPLAIN:
Group (cost=1245130.37..
single process serially.
How does the explain analyze output look like without the HAVING clause?
Try setting parallel_setup_cost and parallel_tuple_cost to 0. That might
trigger parallel query.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Supp
On Wed, Nov 13, 2019 at 3:11 PM Luís Roberto Weck <
luisrobe...@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.c
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
Mariel Cherkassky wrote:
> I wanted to a few questions regarding the parallel parameters :
> max_worker_processes and max_parallel_workers_per_gather.
>
> 1)Basically, max_worker_processes should be set to the number of cpus I have
> in the machine ?
Setting it higher would not be smart.
Setti
We noticed that the following SQL query runs 3 times slower on the latest
version of PostgreSQL with parallel query execution. It would be helpful if
someone could shed light on why this is happening.
Here’s the time taken to execute them on older (v9.5.16) and newer versions
(v11.2) of
ws=4625123 loops=1)
I don't think we have parallel IOS yet (I might be wrong). If so,
it probably thinks this is cheaper than the best available parallel plan.
> If I just get the count it will use a parallel query
Likely a parallelized aggregation.
regards, tom lane
parallel query
explain analyze SELECT count(minion_id) FROM mob_player_mob_118 WHERE
player_id = 55351078;
Thanks
Dave Cramer
12 matches
Mail list logo
