Re: Unexpected planner choice in simple JOIN

Yeah, that seems to do the trick:

test0=# SET parallel_setup_cost=24000;
SET
Time: 0.150 ms
test0=# EXPLAIN ANALYZE SELECT t0.id0, t1.val FROM tab0 AS t0 JOIN tab1
AS t1 ON (t0.id0 = t1.id0) WHERE t0.id0 < 5;
 QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=97.84..64355.16 rows=5000 width=98) (actual
time=0.038..0.819 rows=3500.00 loops=1)
   Buffers: shared hit=113
   ->  Index Only Scan using tab0_pkey on tab0 t0 (cost=0.29..4.38
rows=5 width=4) (actual time=0.003..0.005 rows=5.00 loops=1)
         Index Cond: (id0 < 5)
         Heap Fetches: 0
         Index Searches: 1
         Buffers: shared hit=3
   ->  Bitmap Heap Scan on tab1 t1  (cost=97.55..12837.19 rows=3297
width=98) (actual time=0.023..0.111 rows=700.00 loops=5)
         Recheck Cond: (t0.id0 = id0)
         Heap Blocks: exact=97
         Buffers: shared hit=110
         ->  Bitmap Index Scan on tab1_id0_hash (cost=0.00..96.73
rows=3297 width=0) (actual time=0.018..0.018 rows=700.00 loops=5)
               Index Cond: (id0 = t0.id0)
               Index Searches: 5
               Buffers: shared hit=13
 Planning:
   Buffers: shared hit=9
 Planning Time: 0.168 ms
 Execution Time: 0.935 ms
(19 rows)

A point comes to mind - this is not a particularly unusual setup (i.e
relatively small parent table with big child one), so maybe the defaults
are not ideal here?

Anyway,, thanks for your help!

regards

Mark

On 08/01/2026 17:34, Tom Lane wrote:
> Mark Kirkwood <mark(dot)kirkwood(at)gmail(dot)com> writes:
>> Good suggestion. The results are...interesting:
> It's clear that the planner is underestimating the costs of using a
> parallel worker in your setup. Try increasing parallel_setup_cost
> and/or parallel_tuple_cost to bring things more in line with reality.
>
> regards, tom lane