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