[HN Gopher] Challenges in join optimization
___________________________________________________________________
Challenges in join optimization
Author : HermitX
Score : 29 points
Date : 2026-01-21 17:03 UTC (5 hours ago)
(HTM) web link (www.starrocks.io)
(TXT) w3m dump (www.starrocks.io)
| j-pb wrote:
| Whenever I read join optimisation articles in SQL based systems
| it feels... off.
|
| There is too much heuristic fiddling involved, and way too many
| niche algorithms that get cobbled together with an optimiser.
|
| As if we're missing the theory to actually solve the stuff, so
| we're instead hobbling along by covering as many corner cases as
| we can, completely missing some elegant and profound beauty.
| Sesse__ wrote:
| This post certainly has too much heuristic fiddling! Instead of
| a coherent framework, it takes a bunch of second-rate
| heuristics and tries to use... well, all of them. "Generate at
| most ten plans of this and one of that"? It also has pages and
| pages talking about the easier parts, for some reason (like
| maintaining maps, or that a Cartesian product and an inner join
| are basically the same thing), and things that are just wrong
| (like "prefer antijoins", which is bad in most databases since
| they are less-reorderable than almost any other join; not that
| you usually have much of a choice in choosing the join type in
| the first place).
|
| There _are_ tons of corner cases that you need to address since
| there are some super-hard problems in there (in particular,
| robust cardinality estimation of join outputs is a problem so
| hard that most of academia barely wants to touch it, despite
| its huge importance), but it doesn't need to be this bad.
| Ibrahim26 wrote:
| Yeah Bro I'm a student, so let me learn something new .
___________________________________________________________________
(page generated 2026-01-21 23:00 UTC)