Re: Unexpected planner choice in simple JOIN

From: Mark Kirkwood <mark(dot)kirkwood(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Unexpected planner choice in simple JOIN
Date: 2026-01-08 04:03:01
Message-ID: d9620380-9e84-4256-8593-d3830495dc81@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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!

regards

Mark

On 08/01/2026 16:56, David Rowley wrote:
> On Thu, 8 Jan 2026 at 16:34, Mark Kirkwood <mark(dot)kirkwood(at)gmail(dot)com> wrote:
>> This does seem to be related to parallel planning:
> Isn't it just a case of hash indexes not allowing parallel scans?
>
> David

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message David Rowley 2026-01-08 04:14:55 Re: Unexpected planner choice in simple JOIN
Previous Message David Rowley 2026-01-08 03:56:27 Re: Unexpected planner choice in simple JOIN