JoelJacobson

19 ms·

1.
by JoelJacobson 18d ago
In the article, the linked equivalent query is https://github.com/gregrahn/join-order-benchmark/blob/master... which is written using legacy comma-separated joins and a huge WHERE clause: SELECT MIN(an.
2.
by JoelJacobson 1mo ago
I wonder what a nontrivial multi-table query with joins look like in Acadia?
3.
by JoelJacobson 2mo ago
I'm not a native English speaker, I know "memory safe" has a precise technical meaning, but the word "safe" still feels a bit strange to me given that a memory-safety bug can make the program crash at run-time. Sure
4.
by JoelJacobson 2mo ago
I was amazed by the presentation all the way up until 33:47, where the buggy program compiles and only errors out when the invalid access is executed. So apparently Fil-C enforces memory safety dynamically at run-time , rather than detect
5.
by JoelJacobson 2mo ago
It did fix the original "Postgres LISTEN/NOTIFY does not scale" [1] post's problem though, which was mentioned in an update of that article: Update: Fixed in Postgres core This commit has eliminated the bottlen
6.
by JoelJacobson 2mo ago
Here is the full pgsql-hackers mailing list thread where you can follow our work from initial idea to commit: https://www.postgresql.org/message-id/flat/9d8a4a42-c354-41f...
7.
by JoelJacobson 2mo ago
Back in 2024, I was trying to optimize PostgreSQL's NUMERIC data type, which is base-10000, using Karatsuba. The problem of finding the optimal threshold of when to switch to Karatsuba turned out to be really hard, since it depends on
8.
Ask HN: GLM-5.2 FP8 vs. BF16
1 points by JoelJacobson 3mo ago|0 comments
9.
by JoelJacobson 3mo ago
I was curious what the claim "10-100x uplift in terms of speed compared to Postgres on things like regexp_matches()" was about, so I checked, and DuckDB's regexp_matches() is not the same as PostgreSQL's regexp_matches
10.
by JoelJacobson 3mo ago
Sorry, should have emphasized that it was the "much easier" part I didn't agree with in that interview.
11.
by JoelJacobson 3mo ago
This article made me think of a strange claim by Elon Musk at 07:08 in this [1] interview: "Cooling is actually much easier in space than it is on earth. You can just radiate to the vacuum." I don't think that follows. The r
12.
by JoelJacobson 3mo ago
I think we can't rule out the explanation that all the ideas of space data centers could be connected to a desire by some of finding additional applications for rockets that can transport stuff to space.
13.
by JoelJacobson 4mo ago
Here is a tl;dr as well: https://keyjoin.org/tldr.html
14.
Claude Code vs. Codex: FRA challenge 75746d-2025(gist.github.com)
4 points by JoelJacobson 4mo ago|0 comments
15.
by JoelJacobson 5mo ago
Shame on The Netherlands: ~89% of homes still use natural gas in some way for heating [1], and their government are now "scrapping the obligation to purchase a heat pump in 2026" [2]. [1] https://www.cbs.nl/en-gb&#
16.
by JoelJacobson 5mo ago
Shameless plug: In the upcoming release of PostgreSQL 19, LISTEN/NOTIFY has been optimized to scale much better with selective signaling, i.e. when lots of backends are listening on different channels, patch: https://git.pos
17.
by JoelJacobson 5mo ago
I agree! It should be very stable, IMO. If not, then please send a bug report and we'll look into it. Also, now it scales well with the number of listening connections (given clients listen on unique channel names): https://
18.
by JoelJacobson 9mo ago
Rust without async maybe?
19.
by JoelJacobson 10mo ago
What a really like about concurrent(), is that it improves readability and expressiveness, making it clear when writing and reading that "this code MUST run in parallel".
20.
by JoelJacobson 10mo ago
It's a common misconception that the single queue is a poor design choice. The user reports, of seeing notifications/second severely degrade with lots of backends, cannot be explained by the single-queue design. An efficient imple
21.
by JoelJacobson 10mo ago
In the linked "Optimize LISTEN/NOTIFY" pgsql-hackers, I've shared a lot of benchmark results for different workloads, which also include results on how PostgreSQL currently works (this is "master" in the benchm
22.
by JoelJacobson 10mo ago
Thanks for the report. For that use-case (if you have a single application using a single connection with a LISTEN) then it's expected that is should perform well, since then there is only a single backend which will be context-switche
23.
by JoelJacobson 10mo ago
Here is the Commitfest entry if you want to help with reviewing/development/testing of the patch: https://commitfest.postgresql.org/patch/6078/
24.
by JoelJacobson 10mo ago
> It works, but suddenly your query times explode! Instead of doing 1 million transactions per second* you can now do only 3 (*These numbers were exaggerated for dramatic effect) In general, a single-queue design doesn’t make throughput
25.
by JoelJacobson 10mo ago
> The problem with Postgres' NOTIFY is that all notifications go through a single queue! > Even if you have 20 database connections making 20 transactions in parallel, all of them need to wait for their turn to lock the notificat
26.
by JoelJacobson 10mo ago
> If you call pg_notify or NOTIFY inside a trigger, it will get called 100,000 times and send out 100,000 notifications if you change 100,000 rows in a single transaction which from a performance perspective is ... not ideal. This is onl
27.
by JoelJacobson 10mo ago
I think the sweet spot is to use exceptions for bugs. If the error is expected, make it data.
28.
by JoelJacobson 1y ago
It made me happy to see the pg_get_acl() function that I was involved in adding, is appreciated by users. I think there is still much improvement in the space of querying privileges. I think most users would probably struggle to come up wit
29.
by JoelJacobson 1y ago
I'll add comments to this thread with Github projects that I can find by searching for "postgres listen/notify" on Github. https://github.com/graphile/worker // Line 535 in src/
30.
by JoelJacobson 1y ago
Thanks! I found a link to a GitHub Issue where they described their experienced problems: https://github.com/pulp/pulpcore/issues/6805

More ›