You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem or challenge?
This is part of #13181 for looking into different joins.
What is a Single Join
Single joins are similar to a regular left outer join however the build side can only have zero or one match with the probe side. If there are two or matches for one build side row, it will throw an error during runtime. The reason we need a separate join type for this is because other join types do not keep track of these number of matches.
What is it used for
Single joins are used to optimize scalar subqueries. In Neumann's paper for unnesting subqueries (here), he writes on dependent joins, which is just a join where every iteration of the left side will incur a search on the right side (right side dependent on left).
Here is an example of a scalar subquery:
SELECT
e.name,
(
SELECT d.dept_name
FROM departments d
WHERE d.dept_id = e.dept_id
) AS department
FROM employees e;
Scalar subqueries act as a type of dependent join due to the subquery needing to be calculated for every row on the left. We can eliminate this by creating a hash table out of the subquery side and probing with the build side. This cuts the O(n^2) runtime to O(n). If the build side matches on more than two rows we call an error as it would be an invalid scalar subquery.
I am not sure, perhaps we should also change some planning side things in order to use it more often (or we already queries to other join types effectively - that is also possible).
Activity
jonathanc-n commentedon Jun 17, 2025
take
jonathanc-n commentedon Jun 17, 2025
Thoughts @Dandandan?
jonathanc-n commentedon Jun 20, 2025
Nice follow up for after #16016 gets merged.
Dandandan commentedon Mar 20, 2026
#20999
This has a single join implementation.
So far (as measured on SF=1) I could only see a difference in one of the queries
│ QQuery 23 │ 1027.12 / 1037.06 ±7.15 / 1046.92 ms │ 759.41 / 772.14 ±10.11 / 785.12 ms │ +1.34x faster │I am not sure, perhaps we should also change some planning side things in order to use it more often (or we already queries to other join types effectively - that is also possible).