Re: very slow queries when max_parallel_workers_per_gather is higher than zero

2018-04-16 Thread Guilherme Pereira
Heap Blocks: exact=7 > -> Bitmap Index Scan on > dwh_dm_aabv5kk9rxac4lz_aaonw7nchsan2n1_aad8xhr0m_a_id_euweek_idx > (cost=0.00..4.33 rows=7 width=0) (actual time=0.032..0.032 rows=7 loops=3) > Index Cond

Re: very slow queries when max_parallel_workers_per_gather is higher than zero

2018-04-16 Thread Tomas Vondra
Thanks. So we now have a trivial query demonstrating the issue. IMHO this is not really a costing issue, but due to a misestimate. Essentially, the problem is that the two sides of the join mismatch, causing this: -> Bitmap Heap Scan on dwh_dm ... d (... rows=7 width=4) (...) -> Bitma

Re: very slow queries when max_parallel_workers_per_gather is higher than zero

2018-04-16 Thread Guilherme Pereira
euweek) Planning time: 0.616 ms Execution time: 9611.924 ms (17 rows) On Mon, Apr 16, 2018 at 4:53 PM Pavel Stehule wrote: > > -- Forwarded message - > From: Tomas Vondra > Date: po 16. 4. 2018 16:14 > Subject: Re: very slow queries when max_parallel_workers_pe

Re: very slow queries when max_parallel_workers_per_gather is higher than zero

2018-04-16 Thread Tomas Vondra
Apologies, the reduced query was missing a where condition on id_week: SELECT count(*) FROM f_ticketupdate_aad5jtwal0ayaax AS f INNER JOIN dwh_dm_aabv5kk9rxac4lz_aaonw7nchsan2n1_aad8xhr0m_aaewg8j61iagl1z AS d ON (f.dt_event_id = d.id) WHERE ( 6171 = d."id_euweek" ) regards -- Tomas Vondra

Re: very slow queries when max_parallel_workers_per_gather is higher than zero

2018-04-16 Thread Pavel Stehule
2018-04-16 15:52 GMT+02:00 Tomas Vondra : > > Query Performs nicely, but no parallel workers are used: > > GroupAggregate (cost=2611148.87..2611152.89 rows=31 width=22) (actual > > time=0.084..0.084 rows=0 loops=1) > >Group Key: > > f_zendesktickets_aaeljtllr5at3el.cstm_custom_38746665_primar

Re: very slow queries when max_parallel_workers_per_gather is higher than zero

2018-04-16 Thread Tomas Vondra
> Query Performs nicely, but no parallel workers are used: > GroupAggregate  (cost=2611148.87..2611152.89 rows=31 width=22) (actual > time=0.084..0.084 rows=0 loops=1) >    Group Key: > f_zendesktickets_aaeljtllr5at3el.cstm_custom_38746665_primary_column >    ->  Sort  (cost=2611148.87..2611149.11

Re: very slow queries when max_parallel_workers_per_gather is higher than zero

2018-04-16 Thread Pavel Stehule
2018-04-16 14:00 GMT+02:00 Tomas Vondra : > > > 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 fas

Re: very slow queries when max_parallel_workers_per_gather is higher than zero

2018-04-16 Thread Tomas Vondra
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 2

very slow queries when max_parallel_workers_per_gather is higher than zero

2018-04-16 Thread Pavel Stehule
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 I