| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
| 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 09:49:51 |
| Message-ID: | CAApHDvofBE-oG998LnEWO6aOrZxnh11BtSOK9uDpjoFwahZ65A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
I've no idea how the SQL Server engineers solved that.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2023-09-20 09:53:43 | Re: logical decoding and replication of sequences, take 2 |
| Previous Message | Kuwamura Masaki | 2023-09-20 09:46:32 | Re: bug fix and documentation improvement about vacuumdb |