Revisiting the Algebraic Foundation of Relational Data · HackerPapers discussions

Revisiting the Algebraic Foundation of Relational Data — mentioned by remywang

Sat, 29 Aug 2026 20:08:36 GMT

Compositionality is hard to show with a small example because it really only comes through at scale. If anyone can point me to a huge SQL query, I’ll take it up as a challenge to rewrite in Prela! Prela’s semantics is based on an algebra of binary relations (unfortunately called relation algebra [1]), not the standard relational algebra. [1]: https://arxiv.org/abs/2607.26356

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

Revisiting the Algebraic Foundation of Relational Data — mentioned by remywang

Sat, 29 Aug 2026 19:52:27 GMT

1. Yes 2. No. Prela’s speedup is largely due to indexing. We tried to port the same indexing tricks back to duckdb but it wouldn’t let us. See the paper [1] for details 3. Prela focuses on analytical queries at least for now [1]: https://arxiv.org/abs/2607.26356

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

Revisiting the Algebraic Foundation of Relational Data — mentioned by brof

Tue, 25 Aug 2026 04:12:30 GMT

Got it! One more question if I may: in https://arxiv.org/pdf/2607.26356, all the JOB queries are around a second or less, if I read correctly. My understanding is the query: movie .with(keyword.eq("my-kw")) .select(title) is inlined to something by the compiler approximately like for movie in 0..movie_count { let lo = keyword_offsets[movie]; let hi = keyword_offsets[movie + 1]; for pos in lo..hi { let kw = keyword_ids[pos]; if keyword_text[kw] == "my-kw" { emit(movie, movie_title[movie]); break; } } } So there's no index lookup on keyword, right? E.g., to use a hash index on keyword to find…

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