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 <[email protected]> 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
