very slow queries when max_parallel_workers_per_gather is higher than zero

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: very slow queries when max_parallel_workers_per_gather is higher than zero
Date: 2018-04-16 09:34:11
Message-ID: CAFj8pRDPXZHbJSCTS4dU6YHuUoLVRhJZ3rh_=oZvuk3tAkkJSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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)
-> 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

Regards

Pavel

Attachment Content-Type Size
pg10_regression.sql application/sql 13.2 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martin Swiech 2018-04-16 10:40:54 Postgres 10 problem with UNION ALL of null value in "subselect"
Previous Message Emre Hasegeli 2018-04-16 08:58:35 Re: Standby corruption after master is restarted