remywang

3 ms·

1.
Relation Algebra ≠ Relational Algebra(remy.wang)
7 points by remywang 7d ago|0 comments
2.
by remywang 9d 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 14d 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 14d ago
What website are you talking about? This has nothing to do with AI.
5.
by remywang 14d 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 16d 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 17d 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 17d ago
There has been no movement on this since 2023, and Migicovsky is now busy with reviving pebble
9.
by remywang 17d 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 18d ago
Feline cancer cure slowed by shortage of treats, says my cat
11.
by remywang 27d ago
Thanks! Alloy is also based on TAR, they just call it the more common name of relation algebra (not relational).
12.
by remywang 27d 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 28d ago
They are exactly the same!
14.
by remywang 28d ago
Yes this is correct, thank you.
15.
by remywang 28d 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 28d 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 28d 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 28d 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 28d 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 28d 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 28d 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 28d ago|54 comments
23.
by remywang 1mo 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 1mo 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 1mo ago|4 comments
26.
by remywang 1mo ago
If you like DuckDB, please consider funding DB research [1]! [1]: https://news.ycombinator.com/item?id=49336147
27.
by remywang 1mo 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 1mo ago|1 comments
29.
Ask HN: Who wants to fund DB research?
13 points by remywang 1mo ago|0 comments
30.
Calculus Made Easy by Silvanus P. Thompson (1910)(gutenberg.org)
2 points by remywang 1mo ago|0 comments

More ›