Re: Unexpected planner choice in simple JOIN

On Thu, 8 Jan 2026 at 17:03, Mark Kirkwood <mark(dot)kirkwood(at)gmail(dot)com> 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