remywang

3 ms·

1.
Relation Algebra ≠ Relational Algebra(remy.wang)
7 points by remywang 2mo ago|0 comments
2.
by remywang 2mo ago
I’m so confused, how are you supposed to perform aggregation without reduce? This is like saying “I like plus and times, but I don’t like divide because it’s hard.” I mean sure, but you need it??
3.
by remywang 2mo ago
Very practical approach to “query optimizer as a service”, but I find it cursed that we have decided SQL is the IR for databases
4.
by remywang 2mo ago
What website are you talking about? This has nothing to do with AI.
5.
by remywang 2mo ago
The root of all these is the culture in mathematics (and science in general) to only reward those who “get there first”. This creates a perverse incentive to compete. When no one can out compete a tireless swarm of AI, no one gets rewarded
6.
by remywang 2mo ago
People saying “he should have opted out” are missing the point. OpenAI can and should check their training data for leakage in the face of big breakthroughs like these. It’s the burden of the author to appropriately cite their sources. It’s
7.
by remywang 2mo ago
Light is making a flip phone [1], and it's somewhat hackable now that they release an SDK [2] [1]: https://www.thelightphone.com/shop/products/light-flip [2]: https://developers.thelightphone.com
8.
by remywang 2mo ago
There has been no movement on this since 2023, and Migicovsky is now busy with reviving pebble
9.
by remywang 2mo ago
It's rather convenient for OpenAI that user logs are de-identified before being fed into training, so they can say "there's no way for us to check if we plagiarized our user's work, because user data is private". It
10.
by remywang 2mo ago
Feline cancer cure slowed by shortage of treats, says my cat
11.
by remywang 2mo ago
Thanks! Alloy is also based on TAR, they just call it the more common name of relation algebra (not relational).
12.
by remywang 2mo ago
The remaining 1% is usually uncomfortable if not down right painful. But yes, I agree a query optimizer is valuable. Luckily there’s nothing stopping us from implementing one, as Prela is algebraic and all optimization techniques for SQL ca
13.
by remywang 2mo ago
They are exactly the same!
14.
by remywang 2mo ago
Yes this is correct, thank you.
15.
by remywang 2mo ago
Ah, that's not what I meant to say. You're talking about bag vs set semantics. Prela implements bag semantics just like SQL. That sentence should say "a binary relation can map an input to multiple different outputs",
16.
by remywang 2mo ago
Author here, I will be at VLDB in Boston this coming week and will be very happy to chat about Prela. Unrelated, we also have a tutorial on instance-optimal join algorithms: https://www.vldb.org/2026/program.html#tut-2
17.
by remywang 2mo ago
With some syntax sugar it looks almost exactly like SQL [1]. Here I’m showing the unsweetened edition for didactic purposes. [1]: https://remy.wang/blog/prela.html
18.
by remywang 2mo ago
Here are some SQL queries from standard benchmarks rewritten in Prela: https://github.com/remysucre/prela/tree/cidr#queries This is in rust and we’re still tweaking the language, so the syntax is slightly dif
19.
by remywang 2mo ago
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
20.
by remywang 2mo ago
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:&#x
21.
by remywang 2mo ago
The point of Prela is exactly to remove that step of indirection, it gives you ORM ergonomics but compiles directly to operations on the physical columns, skipping SQL. At least for me I find it easier to think in Prela than to think in SQL
22.
A better SQL in 11 lines of code(prela-lang.org)
44 points by remywang 2mo ago|54 comments
23.
by remywang 3mo ago
Yes basically. But DuckDB actually does not build an index on the keyword text. It only builds primary key indices automatically on data load. The standard benchmark schema specifies fk indices but not one for the keyword text.
24.
by remywang 3mo ago
Thank you! Prela’s `.and` operator is exactly the fork in fork algebra. I also suspect you will get `.select` and `.and` if you lift >>> and &&& to the category of Rel. > I wonder where the limitations of this approa
25.
What if SELECT, FROM, WHERE were functions?(remy.wang)
4 points by remywang 3mo ago|4 comments
26.
by remywang 3mo ago
If you like DuckDB, please consider funding DB research [1]! [1]: https://news.ycombinator.com/item?id=49336147
27.
by remywang 3mo ago
Remy Wang, Assistant Professor @ UCLA https://remy.wang Working on: - Query languages (Prela [1] and Datalog) - Join algorithms (WCOJ, instance-optimal joins [2], join ordering) [1]: https://prela-lang.org [2]: http
28.
Ask HN: Who needs funding for DB research?
3 points by remywang 3mo ago|1 comments
29.
Ask HN: Who wants to fund DB research?
13 points by remywang 3mo ago|0 comments
30.
Calculus Made Easy by Silvanus P. Thompson (1910)(gutenberg.org)
2 points by remywang 3mo ago|0 comments

More ›