remywang

6 ms·

1.
by remywang 5d 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
2.
by remywang 5d ago
What website are you talking about? This has nothing to do with AI.
3.
by remywang 5d 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
4.
by remywang 6d 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
5.
by remywang 7d 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
6.
by remywang 7d ago
There has been no movement on this since 2023, and Migicovsky is now busy with reviving pebble
7.
by remywang 7d 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
8.
by remywang 9d ago
Feline cancer cure slowed by shortage of treats, says my cat
9.
by remywang 18d ago
Thanks! Alloy is also based on TAR, they just call it the more common name of relation algebra (not relational).
10.
by remywang 18d 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
11.
by remywang 18d ago
They are exactly the same!
12.
by remywang 18d ago
Yes this is correct, thank you.
13.
by remywang 18d 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",
14.
by remywang 18d 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
15.
by remywang 18d 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
16.
by remywang 18d 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
17.
by remywang 18d 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
18.
by remywang 18d 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
19.
by remywang 18d 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
20.
A better SQL in 11 lines of code(prela-lang.org)
44 points by remywang 18d ago|54 comments
21.
by remywang 22d 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.
22.
by remywang 24d 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
23.
What if SELECT, FROM, WHERE were functions?(remy.wang)
4 points by remywang 28d ago|4 comments
24.
by remywang 1mo ago
If you like DuckDB, please consider funding DB research [1]! [1]: https://news.ycombinator.com/item?id=49336147
25.
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
26.
Ask HN: Who needs funding for DB research?
3 points by remywang 1mo ago|1 comments
27.
Ask HN: Who wants to fund DB research?
13 points by remywang 1mo ago|0 comments
28.
Calculus Made Easy by Silvanus P. Thompson (1910)(gutenberg.org)
2 points by remywang 1mo ago|0 comments
29.
by remywang 1mo ago
Looks like Andy's here, so if you see this - please also try to convince ClickHouse to consider funding DB research in academia. With all the money being poured into AI and the chaos in government funding, there is almost nothing for D
30.
by remywang 2mo ago
That’s because syntax is the least interesting part of F*.

More ›