Re: very slow queries when max_parallel_workers_per_gather is higherthan zero - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: very slow queries when max_parallel_workers_per_gather is higherthan zero
Date
Msg-id b8af5699-fe30-1940-71c1-36bdbba72f76@2ndquadrant.com
Whole thread Raw
In response to very slow queries when max_parallel_workers_per_gather is higher than zero  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: very slow queries when max_parallel_workers_per_gather is higherthan zero  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers

On 04/16/2018 11:34 AM, Pavel Stehule wrote:
> Hi,
> 
> my customer does performance checks of PostgreSQL 9.5 and 10. Almost all
> queries on 10 are faster, but there are few queries (40 from 1000) where
> PostgreSQL 9.5 is significantly faster than. Unfortunately - pretty fast
> queries (about 20ms) are too slow now (5 sec).
> 
> attached execution plans
> 
> It looks like some cost issue, slow queries prefers Seq scan against
> bitmap heap scan
> 
> Hash Cond: (f_ticketupdate_aad5jtwal0ayaax.dt_event_id =
> dwh_dm_aabv5kk9rxac4lz_aaonw7nchsan2n1_aad8xhr0m_aaewg8j61ia.id
> <http://dwh_dm_aabv5kk9rxac4lz_aaonw7nchsan2n1_aad8xhr0m_aaewg8j61ia.id>)
>    ->  Parallel Seq Scan on f_ticketupdate_aad5jtwal0ayaax 
> (cost=0.00..1185867.47 rows=24054847 width=8) (actual
> time=0.020..3741.409 rows=19243863 loops=3)
>    ->  Hash  (cost=27.35..27.35 rows=7 width=4) (actual
> time=0.089..0.089 rows=7 loops=3)
>         Buckets: 1024  Batches: 1  Memory Usage: 9kB
> 
> 

What happens when you disable sequential scans on pg10?

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Problem while updating a foreign table pointing to a partitionedtable on foreign server
Next
From: Laurenz Albe
Date:
Subject: Re: SHOW ALL does not honor pg_read_all_settings membership