radimm

OP, here thank you for comments and while I might not like it to be called LLM - I give up.

well, let's say it depends what audince. This particular topic came as part of talks I deliver on Postgres internals and my webinars. Same story. Again and again.

But I do get the point. Here the goal was - there's no perfect solution. Just characteristics to be aware of.

Given the anti-LLM sentiment here I need to get offline and not get affected by it.

OP here, thanks for the feedback. Just curious - anything specific? I spent long time getting to some sort of framework for my writing and being called LLM is my constant struggle.

PS: I do use LLM for polish, etc.

I had to make a cut - and that's also a reason why etcd got mentioned - focused on what most people today know.

OP here, I acctually had Firebird listed in some version of my draft, but had to make a natural cut somewhere.

OP here - thanks for feedback. They weren't in prompt because there wasn't any (for polish yeah, not hiding it).

OP here - correct, I guess I should clarify soon.

Thank you! And you are right. Many people forgot about idle-in-transaction backends.

Full comparison https://docs.hetzner.com/general/infrastructure-and-availabi...

For example CPX 42 went from € 0.0408/h (25.49 per month) to € 0.1114/h (69.49 per month).

Was expecting price hike but not this level.

Markus never fails to deliver. I actually haven’t realised how SQL standard handles ORDER BY on non-selected columns by just rewriting the SELECT clause behind your back.

Separation of concerns ruthlessly broken ;-)))

Somehow it feel HOT updates are very confusing. You can also try to play with interactive visualizer to understand it better https://boringsql.com/visualizers/hot-updates/

This is the message the author posted on LinkedIn:

After a lot of thought, I have decided to stop working on pgBackRest. I did not come to this decision lightly. pgBackRest has been my passion project for the last thirteen years, and I was fortunate to have corporate sponsorship for much of this time, but there were also many late nights and weekends as I worked to make pgBackRest the project it is today, aided by numerous contributors. Every open-source developer knows exactly what I mean and how much of your life gets devoted to a special project.

Since Crunchy Data was sold, I have been maintaining pgBackRest and looking for a position that would allow me to continue the work, but so far I have not been successful. Likewise, my efforts to secure sponsorship have also fallen far short of what I need to make the project viable.

Like everyone else, I need to make a living, and the range of pgBackRest-related roles is very limited. I can now consider a wider variety of opportunities, but those will not leave me time to work on pgBackRest, which requires a fair amount of time for maintenance, bug fixes, PR reviews, answering issues, etc. That does not even include time to write new features, which is what I really love to do. Rather than do the work poorly and/or sporadically, I think it makes more sense to have a hard stop.

I will post a notice of obsolescence and archive the repository. I imagine at some point pgBackRest will be forked, but that will be a new project with new maintainers, and they will need to build trust the same way we did.

Again, many thanks to all the pgBackRest contributors over the years. It was a pleasure working with you!

One of the benefit is that instead of LLM blindly advising you to do

> ALTER TABLE customers ALTER COLUMN email SET NOT NULL;

it can advise you to

-- Step 1: backfill NULLs UPDATE customers SET email = 'unknown-' || id || '@example.com' WHERE email IS NULL;

-- Step 2: add constraint without full table scan ALTER TABLE customers ADD CONSTRAINT customers_email_not_null CHECK (email IS NOT NULL) NOT VALID;

-- Step 3: validate in the background with a weaker lock ALTER TABLE customers VALIDATE CONSTRAINT customers_email_not_null;

Thanks - I will recheck later today.

OP here, damn - that's a very good point. Can't believe I missed it.

This is exactly same struggle for me. Writing technical content about PostgreSQL and balancing my voice without sounding like LLM written is genuinely difficult.

As English is not my first language, I do run into problem where the line between fix my clumsy sentence and rewrite my thought is very thin. Same with writing "boring" technical explanation and more approachable content. I'm getting pushed back for both.

Not OP - but definitely no. In such a case use just physical or - if you have special use case - logical replication that’s built in.

OP here - still have to try (generally operate on VM/bare metal level); but my understanding is that ioctl call would get passed to the underlying volume; i.e. you would have to mount volume

OP here - yes, this is my use case too: integration and regression testing, as well as providing learning environments. It makes working with larger datasets a breeze.

Actually, a "ghost station" shell has existed under Satellite 3 since 1998, though it was never finished or opened to passengers. The tunnel was built that far just to give the trains space to turn around.

Yes, I'm Czech.

I wouldn't usually use the 'non-native speaker argument', but thank you! Just yesterday I was accused of sounding like AI - https://news.ycombinator.com/item?id=46262777 - my default mode is that I oscillate between sounding too boring/technical, or when trying to do my best, sounding like AI

OP here - thank you for mentioning replica, forgot to mention it. Unless it would hit it pretty hard and `hot_standby_feedback` is on

Author here – it’s actually funny, as you pointed out parts that are my own (TM) attempts to make it a bit lighthearted.

LLM is indeed used for correction and improving some sentences, but the rest is my honest attempt at making writing approachable. If you’re willing to invest the time, you can see my fight with technical writing over time if you go through my blog.

(Writing this in the middle of a car wash on my iPhone keyboard ;-)

Author here - thank you for the comments. This article is indeed playing a lot on verge of clickbait and I did asked about that shortly after publishing.

Hey, thank you for follow-up. Really appreciated. This is why I decided to go out and show RegreSQL.

You're absolutely right that in an ideal world, every project would have solid integration tests covering their database access queries. That's the goal everyone should aim for. Unfortunately there again and again cases where developers are afraid of SQL and databases and it's not uncommon to see very simple things sending applications to crawl.

As for the second point, that's a direction I would love to get. Whatever it can be directly, as part of open source or service is something to be decided - but tracking the trend data there would provide a lot of value indeed.

Let me be clear - this is just baseline testing that's only valid for similar data patterns, same cardinality, and so on. Plus it's currently using EXPLAIN, so we're working with estimates, not actual execution data.

But from my experience, this is low-hanging fruit for catching regressions that could break your application without you noticing. The performance work you're describing is the real nitty-gritty database management - the deep optimization work that truly makes or breaks an app.

For that there's no silver bullet.

For now the syntax is not fully compatible - but my goal is to add https://github.com/boringSQL/queries (library behind SQL files parsing) to better align on it. It's definitely on my radar

I'm obviously biased. Adding MySQL support is not that difficult but maintenance is (and ultimately PostgreSQL is better way forward (half joking :))

With current feature set it's something I have already considered but still undecided.