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