4 ms·

Neat, but.. > Cause it turns out, hey, a join is really simple! All it's doing is basically computing the Cartesian Product of your two tables, and then filter

Neat, but.. > Cause it turns out, hey, a join is really simple! All it's doing is basically computing the Cartesian Product of your two tables, and then filtering out rows based on how you specified the query. No big deal. Was this a simplification or that's how you think JOINs work? In either case, it's an extremely misleading statement.

Xcelerate 8y ago
Other than some implementation tricks (optimizing broadcast joins, etc.), how is he wrong? That’s basically the definition of a JOIN.
- skybrian 8y ago
  The "implementation tricks" are essential optimizations.
  - elcritch 8y ago
    For most usable systems, sure. For a functionally correct but slow implementation, nope.
  - e12e 8y ago
    Technically JOIN without a where could mean CROSS JOIN? https://en.m.wikipedia.org/wiki/Join_(SQL)#Cross_join https://en.m.wikipedia.org/wiki/Join_(SQL)#Cross_join
nathandaly 8y ago
Thanks, no, i think this is a good criticism. I think what I meant was something more like "You can think of it as basically just the Cartesian Product of your two tables, and then filtering out rows based on how you specified the query." I'll make that change now. I recognize that you would want to do the filtering first, of course, and only materialize the final table at the very end after everything else finishes. Other than that, though, am I missing anything else? It's quite possible due to, as I said, how new I am to relational databases.
- elcritch 8y ago
  Fun project! I think Julia could be a great language for implementing things like using Bayesian statistical methods for estimating efficient query plans. :-) Do you use the new iterators to implement the joins? If so, it seems reasonable that you could implement the join/filter as logical separate components but have the filtering happen in-line with the joins during iteration. Then you'd get the best of both worlds. It'd be interesting to see how well the Julia jit can inline that type of code! Also, if you're just getting into relational databases, definitely take some time to read up on the relational calculus, and relational algebra.

Xcelerate 8y ago

Other than some implementation tricks (optimizing broadcast joins, etc.), how is he wrong? That’s basically the definition of a JOIN.

skybrian 8y ago
The "implementation tricks" are essential optimizations.
- elcritch 8y ago
  For most usable systems, sure. For a functionally correct but slow implementation, nope.
- e12e 8y ago
  Technically JOIN without a where could mean CROSS JOIN? https://en.m.wikipedia.org/wiki/Join_(SQL)#Cross_join https://en.m.wikipedia.org/wiki/Join_(SQL)#Cross_join

nathandaly 8y ago

Thanks, no, i think this is a good criticism. I think what I meant was something more like "You can think of it as basically just the Cartesian Product of your two tables, and then filtering out rows based on how you specified the query." I'll make that change now. I recognize that you would want to do the filtering first, of course, and only materialize the final table at the very end after everything else finishes. Other than that, though, am I missing anything else? It's quite possible due to, as I said, how new I am to relational databases.

elcritch 8y ago
Fun project! I think Julia could be a great language for implementing things like using Bayesian statistical methods for estimating efficient query plans. :-) Do you use the new iterators to implement the joins? If so, it seems reasonable that you could implement the join/filter as logical separate components but have the filtering happen in-line with the joins during iteration. Then you'd get the best of both worlds. It'd be interesting to see how well the Julia jit can inline that type of code! Also, if you're just getting into relational databases, definitely take some time to read up on the relational calculus, and relational algebra.