Live data from Hacker News

Scaling PostgreSQL to power 800M ChatGPT users

openai.com

141–145 of 145 posts

Re: Scaling PostgreSQL to power 800M ChatGPT users

#141

Earlier quoted context omitted.

We have a similar check in our Haskell codebase, after running into two issues: 1. Nested database transactions could exhaust the transaction pool and deadlock 2. Same as you described with doing eg HTTP during transactions We now have a compile time guarantee that no IO can be done outside of whitelisted things, like logging or getting the current time. It’s worked great! Definitely a good amount of work though.

I figured it’d be Haskell that is able to do this sort of thing really well. :-D I had this realization while writing the rustc plugin that this is basically another shade of “function coloring”, but done intentionally. Now I wish I could have a language that lets me intentionally “color” my functions such that certain functions can only be called from certain blessed contexts… not unlike how async functions can only…

It sounds super cool, your idea and implementation for await and transactions. Because of my limited Rust knowledge, it's hard for me to understand how difficult it was to implement such a plugin.

Also, your idea of using different domain specific colors is interesting. It might be possible to express this via some kind of effect system. I'm not aware of any popular Rust libraries for that, but it could be worth borrowing some ideas from Scala libraries.

Re: Scaling PostgreSQL to power 800M ChatGPT users

#142

Article has so much fluff and only some very coarse information like (we sharded writes, yay!). Almost no detail just keywords for SEO, or whatever they’re aiming for. There’s also a lot of repetition. Maybe it was AI generated…?

I think it could even backfire as a piece of corporate promotion.

Re: Scaling PostgreSQL to power 800M ChatGPT users

#143
post #48

Earlier quoted context omitted.

Why is it a good database? Integration with Entra? I've heard arguments in favor of Oracle DB, but I've never heard anything good about MSSQL besides integration with the MS ecosystem.

The SQL Server query planner is head and shoulders above what Postgres offers in the types of optimizations it will apply to your queries. It also properly caches query plans. It offers heap tables, as well as index organized tables depending on what you need. The protocol supports running multiple queries and getting multiple resultsets back at once saving some round-trips and resources. Also supports things like gl…

[deleted]

Re: Scaling PostgreSQL to power 800M ChatGPT users

#144
post #119

Earlier quoted context omitted.

How did you implement this runtime check? Is it a lint rule, or using the type system?

It’s a compile-time check, and yeah it’s a lint rule. In fact it goes a little deeper than a lint can go, because it uses data from earlier compiler phases (in order to get access to what the borrow checker knows.) The correct terminology is a “rustc driver” from what I’ve heard. Lints like clippy run as a “LateLintPass”, which doesn’t have access to certain mir data that is intentionally deleted in earlier phases to…

Very cool, thanks for sharing! Please let me know if you end up open sourcing this!

Re: Scaling PostgreSQL to power 800M ChatGPT users

#145
I was surprised to see this:

> If joins are necessary, we learned to consider breaking down the query and move complex join logic to the application layer instead.

We often try to leverage the power of the DB to optimize joins on our behalf to avoid having to create them. At a certain point, I guess you wind up having to pull this back to your layer to optimize "the one job" of the database.

I jest, but only slightly. We don't just want to persist data, but link it for different purposes, the "relational" part of RDBMS. Good to know there's still room to grow here, for PostgreSQL and the DB industry.

Post reply on HN