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) (...) -> Bitmap Heap Scan on f_ticketupdate_aad5jtwal0ayaax f (cost=1633.90..214617.67 rows=87472 width=4) (actual time=0.003..0.003 rows=0 loops=7) Recheck Cond: (dt_event_id = d.id) -> Bitmap Index Scan on f_ticketupdate_aad5jtwal0ayaa ... (cost=0.00..1612.03 rows=87472 width=0) (actual time=0.003..0.003 rows=0 loops=7) Index Cond: (dt_event_id = d.id) I.e. the database believes the bitmap index scan will match 87k rows. But in fact it matches 0, which makes the bitmap heap scan entirely unnecessary (thus costing nothing, because it's skipped). Of course, the parallel plan is structured slightly differently, and does not allow this skipping because it places the f_ table on the outer side of the join (and scans it using sequential scan). Now, try changing the parameters (particularly id_euweek) so that the bitmap index scan actually matches something. I'm pretty sure that will make the non-parallel case much more expensive. Increasing the parallel_setup_cost makes the parallel plan a bit more expensive, enough to switch to the non-parallel plan. But that's mostly a fluke and not particularly principled way to fix this - if the cost difference gets a bit larger (or if you increase the number of parallel workers) it's probably going to use the parallel plan again. Obviously, PostgreSQL 9.5 doesn't have parallel queries, so it does not have a chance of making this mistake. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services