From: | "Lepikhov Andrei" <a(dot)lepikhov(at)postgrespro(dot)ru> |
---|---|
To: | "David Rowley" <dgrowleyml(at)gmail(dot)com> |
Cc: | "Benjamin Coutu" <ben(dot)coutu(at)zeyos(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Peter Geoghegan" <pg(at)bowt(dot)ie> |
Subject: | Re: disfavoring unparameterized nested loops |
Date: | 2023-09-20 15:17:46 |
Message-ID: | db387e04-beb5-4454-8ad7-e358d3308e12@app.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 20, 2023, at 4:49 PM, David Rowley wrote:
> On Wed, 20 Sept 2023 at 19:56, Andrey Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
>> What could you say about a different way: hybrid join? In MS SQL Server,
>> they have such a feature [1], and, according to their description, it
>> requires low overhead. They start from HashJoin and switch to NestLoop
>> if the inner input contains too small tuples. It solves the issue, Isn't it?
>
> A complexity which you may not be considering here is that Nested Loop
> joins always preserve the tuple order from the outer side of the join,
> whereas hash joins will not do this when multi-batching.
My idea here is the same as MS SQL guys did: prefetch from the HashJoin inner some predefined number of tuples and, if the planner has made a mistake and overestimated it, move hash join inner to NestLoop as an outer.
The opposite strategy, "underestimation" - starting with NestLoop and switching to HashJoin looks more difficult, but the main question is: is it worthwhile to research?
> I've no idea how the SQL Server engineers solved that.
--
Regards,
Andrei Lepikhov
From | Date | Subject | |
---|---|---|---|
Next Message | Damir | 2023-09-20 16:15:15 | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |
Previous Message | Alvaro Herrera | 2023-09-20 14:59:49 | Re: Dump-restore loosing 'attnotnull' bit for DEFERRABLE PRIMARY KEY column(s). |