On Thu, 8 Jan 2026 at 17:03, Mark Kirkwood <[email protected]> wrote: > > I don't think so - while the case I posted used a hash index on the > child table, exactly the sane behaviour happens if it is a btree (I > probably should have mentioned that sorry). Background is I discovered > this while playing about with hash indexes...which I must say - someone > has done excellent work on as in this *particular cases* they are > getting me better query performance!
Ok, it seems related to the min_parallel_index_scan_size GUC. If you zero that, do you get a better plan? I think the problem is that because the best form of plan for joining this tiny set of rows to the huge table is a parameterised nested loop, to parallelise that loop, you need a Parallel node on the outer side of the Nested Loop. If the index's size is below min_parallel_index_scan_size then we won't build a partial path for it. David
