Worst-Case Optimal Join Algorithms: Techniques, Results, and Open Problems · HackerPapers discussions

Worst-Case Optimal Join Algorithms: Techniques, Results, and Open Problems — mentioned by j-pb

Sun, 03 Jan 2021 10:24:49 GMT

It's all about efficient range reads and seek operations. You can compute set operations pretty efficiently using sorted indices that support a "find next or greater" operation. For intersection, take the first value from the first set as the smallest candidate of the output set, then call call candidate := next(candidate) on each set, updating the candidate with the next smallest possible value, and adding it to the output set when a candidate was returned by all sets. The algorithm is worst case optimal up to a log factor, and can even be extended to perform generic constraint programming…

Paper and discussion history. A mention is not an endorsement.

Worst-Case Optimal Join Algorithms: Techniques, Results, and Open Problems — mentioned by refset

Sun, 15 Dec 2019 00:38:57 GMT

Crux uses a Worst-Case Optimal Join [0] algorithm with bitemporal indexes, and the Datalog-specific query layer is implemented in less than a thousand lines of Clojure: https://github.com/juxt/crux/blob/master/crux-core/src/crux/... SQL certainly provides a lot of bells and whistles but Crux has the advantage of consistent in-process queries (i.e. the "database as a value") which means you can combine custom code with multiple queries efficiently to achieve a much larger range of possibilities, such as graph algorithms like Bidirectional BFS [1]. [0] https://arxiv.org/pdf/1803.09930.pdf [1]…

Paper and discussion history. A mention is not an endorsement.