levkk

You either die a hero or live long enough to become the villain. Fork it, run it, make it better. That's the gift of GPL. Just because you can't spin it up on EC2 (yet) doesn't make it a worse kernel. Lots of hosting providers accept custom images.

From a business perspective, it's a long time to get to your first dollar.

It's kinda crazy that Partiful existed for over 7 years, has series A funding, and yet is completely free.

If I could run SoTA models on my desktop, you would be onto something. While it's a subscription, the big guys who own the data centers will do whatever the guys in government tell them to. TLDR: you'll start getting the "I can't assist you with this task" reply to all your prompts.

Yuuuup. Which I guess makes it even harder to detect what's AI and what's not.

That defeats the purpose. If I have an email, I want to be reachable. We just need a good spam detector...oh wait, that's pretty much solved already :)

Anyway, nothing against the posted project! I think it's cool.

No such thing. Business, like history, goes in circles.

We disabled PRs for PgDog, but left the issues open, for now.

Most bugs that are reported via AI-generated GitHub issues are edge cases, which are technically bugs, but not something anyone actually ran into.

Contributions are exclusively AI-generated, and it's much easier to just go off of a GitHub issue myself than asking the bot behind the GH account to remove the 5 redundant tests it added, or to refactor what has become a 3k line file.

AI doesn't care about code quality, maintenability, or long term goals. It's just a local maximum optimized with RL. Great for debugging, OK for reviews, but can't produce anything that's above average.

That's how you push the field forward. Good isn't good enough.

116% would be 2x which will break the laws of physics. 16% is possible if you're not allocating heap memory, which I believe is the main selling point here.

Curious to compare your implementation to ours [1] some day (if you guys open source it).

[1]: https://docs.pgdog.dev/features/sharding/2pc/

Same here! Except:

- PgDog is open source

- It runs anywhere, not just your cloud

- It's built for Postgres, not a MySQL pivot

Oh no! Anyway...

I personally have thousands of hours in _both_ WoW and Counter Strike, and yet ...

Not if he can also deliver equally good or better results, which I suspect he will. Not everyone needs it to do a good job, and for others, it could be a net negative.

Using computers created an unambiguous productivity boost. Same cannot be said for all types of software engineering with AI; that's why we keep having this debate. The results are mixed.

We don't maintain it anymore. I'm working on pgdog[1] fulltime now. We've had several successful pgcat -> pgdog migrations now.

[1] https://github.com/pgdogdev/pgdog

There is a difference between using an electric drill and having a robot assemble the entire car.

Yup. Getting pretty tired from seeing these "0days" that are not exploitable in any real use case. Just vibes, no substance.

Kagi is amazing. Worth the subscription, 10 times over. I don't have to worry about sponsored search results, or slop from the "AI overview". High quality results, like Google used to be.

For a price of two cups of coffee.

This is nonsense. Tokio was built for I/O, not crunching numbers. Most programmers know to use spawn_blocking to crunch 10MB JSON, if needed.

Additionally, the proposed workload per thread model will be orders of magnitude slower than Tokio for I/O-bound workloads, which most applications are.

I think most tools, according to the UNIX philosophy, do one thing (and do it well). AI is a tool that does _a lot_ of things...to various degrees of success. While you can verify that the output of `sed` or `grep` is valid, you can't with 10k lines of code you have no context on (without _significant_ effort).

Same with Gimp, Firefox, and your terminal. Tools, all, do many easily verifiable things. AI isn't verifiable without an existing framework, and that's why it's so "good" at rewriting code from language A to language B, but not at zero-to-one building real world software.

Glad you like it. It was built to fix some of PgBouncers shortcomings that we ran into at Instacart many years ago, and to have a stronger foundation for scaling Postgres horizontally (that's sharding)!

Ouf. I don't know. I don't want to call you out without evidence -- I myself make benchmark claims all the time -- but 50% improvement in OLTP seems suspicious. I get that you used a standard benchmark, and I don't even know what it entails, but my spidey sense is going off. Perhaps, some trade off somewhere that won't make it to prod because it breaks MVCC -- and yes, I saw that it passes regression tests.

Just checking, is fsync on? :) Regression tests don't catch bad IO patterns afaik.

Anyway... sounds like a fun project to work on!

Pin the client temporarily. I'm assuming that our users know what they are doing. I could be wrong, but so far so good.

Yes. The plugin architecture supports this currently. That being said, you can use any number of sharding functions we support to do this too.

Thanks! We try to be very open and explicit about why we chose AGPL. Personally, I like it because it's an extension of GPL, which is a huge reason why I was able to self-teach programming. Just trying to give back.

Handling cursors is tough - they are very much session-level objects, so even if we, say, pinned your client while it uses that cursor, which would work, that would decrease the performance of connection pooling overall.

So, what's better, breaking your app initially so you know to remove that feature, or letting it work silently while the connection pool isn't 100% in transaction mode? Tough call.

I don't think so. Too much trouble. Caching is a really hard problem without context, and the context, typically, is app-specific.

From the strictest CAP theorem definition, that's correct, it is not. But, it's pretty close. I know that in the database world, that's not a good answer, but in practice, it will deliver the vast majority of messages, so maybe that's good enough? We'll see.

We show that it's possible to come close without breaking the DB or the app, but I suspect, it's not quite yet at the level you'd expect from a _durable_ work queue, e.g., Kafka. Not going to replace that one anytime soon.

Very cool. At first, I thought it was yet another LLM-generated demo, but no: original work of art. Super cool. Transpiling into C does seem easier than LLVM IR, and letting GCC optimize seems like this might actually work.

Excited to see the compiler implementation when it's out -- a lot to learn from.