I'm conflicted with this article. It does pack a lot of good information in there, and it's a useful comparison of the core difference between PostgreSQL and MySQL. But it still contains a lot of LLM-isms which are off putting and make me want to stop reading when I see them.
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.
- the bloat, the amplified writes, the vacuum babysitting
- every charge traces to a decision, not a defect
- the verdict that spreads from community to community always stops one question early
- watch the damage happen yourself
Here's one way of how to write it in simpler language:
> These are not user mistakes and it's easy to reproduce these issues in a few lines of SQL on the latest version of Postgres. We're going to go through each of these problematic cases one by one to understand what's happening. Next, we're going to look at how other databases are solving it. Turns out there is no silver-bullet here: Postgres just makes a different set of trade-offs than other databases.
I think jdnier nailed the phrases that most stuck out for me. I also agree that I would rather hear your own voice, even if you think it's less polished.
The problem is when reading something that has those LLM tells, I immediately wonder if any of the information has been vetted, and I wonder just how much LLM-fluff I'm going to have to wade through to get the information.
I can see you didn't just let the LLM do everything here and your own experience has guided and shaped the article. It is a good article overall, but the LLM-isms create a nagging sense of doubt about the quality which is hard to shake.
For me it's the rythm. It's a list of chapters, each with a list of subchapters, plenty of bulleted lists, and paragraphs of close to equal size with sentences of close to equal size. Everything is trying to be an element with an impact. Each sentence, each paragraph, each entry in a list, each list, each subchapter... feels like I'm being hit with an impact drill. This! Then this! Now this! Conclusion! But there's more!
Do all the writing yourself, use LLMs for research and as an editor only. When using an LLM as an editor never copy its verbatim suggestion into your prose.
Same. It's really hard to fight the tic now where I just automatically close the tab when I get to the second or third thing, and it's only the first paragraph.
> Nothing was solved. The four questions got new answers, and the costs moved into the compactor.
I have been meaning to write on this topic and in relation to LSM for a while. So, I appreciated that note on LSMs. There are no free ~lunches~ reads or writes.
I see. I guess that makes sense, popularity-wise. I imagine the results were in the vicinity of PostgreSQL anyway, considering the similarity of approaches.
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.
Dupe of https://news.ycombinator.com/item?id=49078196 which was posted a couple days ago, and then seemingly revived in second chance pool before getting flagged for obvious slop-tone.
I'm conflicted with this article. It does pack a lot of good information in there, and it's a useful comparison of the core difference between PostgreSQL and MySQL. But it still contains a lot of LLM-isms which are off putting and make me want to stop reading when I see them.
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.
Some examples just from the second paragraph:
- while none of this is exaggerated
- it comes down to a real design choice
- the bloat, the amplified writes, the vacuum babysitting
- every charge traces to a decision, not a defect
- the verdict that spreads from community to community always stops one question early
- watch the damage happen yourself
Here's one way of how to write it in simpler language:
> These are not user mistakes and it's easy to reproduce these issues in a few lines of SQL on the latest version of Postgres. We're going to go through each of these problematic cases one by one to understand what's happening. Next, we're going to look at how other databases are solving it. Turns out there is no silver-bullet here: Postgres just makes a different set of trade-offs than other databases.
I think jdnier nailed the phrases that most stuck out for me. I also agree that I would rather hear your own voice, even if you think it's less polished.
The problem is when reading something that has those LLM tells, I immediately wonder if any of the information has been vetted, and I wonder just how much LLM-fluff I'm going to have to wade through to get the information.
I can see you didn't just let the LLM do everything here and your own experience has guided and shaped the article. It is a good article overall, but the LLM-isms create a nagging sense of doubt about the quality which is hard to shake.
For me it's the rythm. It's a list of chapters, each with a list of subchapters, plenty of bulleted lists, and paragraphs of close to equal size with sentences of close to equal size. Everything is trying to be an element with an impact. Each sentence, each paragraph, each entry in a list, each list, each subchapter... feels like I'm being hit with an impact drill. This! Then this! Now this! Conclusion! But there's more!
It's not a human way to think, talk or write.
Tells like "load-bearing" and "real", for example.
"the heap's simplicity is load-bearing: once..."
"It's a real thing"
"It's a real trade-off"
"The design buys real things"
"it comes down to a real design choice"
"That's a real critique"
Do all the writing yourself, use LLMs for research and as an editor only. When using an LLM as an editor never copy its verbatim suggestion into your prose.
Really, don't use LLM for polish; that's what wrecks it imho. People write idiosyncratically and that's a good thing. That's your voice.
I would say ignore them. It was well written an informative. Some people have just gone insane and see LLMs everywhere.
[dead]
[dead]
Same. It's really hard to fight the tic now where I just automatically close the tab when I get to the second or third thing, and it's only the first paragraph.
Please, write your own prose.
> Nothing was solved. The four questions got new answers, and the costs moved into the compactor.
I have been meaning to write on this topic and in relation to LSM for a while. So, I appreciated that note on LSMs. There are no free ~lunches~ reads or writes.
I'm surprised that Interbase/Firebird seems to be entirely omitted from this despite pioneering the MVCC approach.
OP here, I acctually had Firebird listed in some version of my draft, but had to make a natural cut somewhere.
I see. I guess that makes sense, popularity-wise. I imagine the results were in the vicinity of PostgreSQL anyway, considering the similarity of approaches.
I had to make a cut - and that's also a reason why etcd got mentioned - focused on what most people today know.
but that approach doesn't teach "most of your audience" something new that they didn't know before
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 thank you for comments and while I might not like it to be called LLM - I give up.
Dupe of https://news.ycombinator.com/item?id=49078196 which was posted a couple days ago, and then seemingly revived in second chance pool before getting flagged for obvious slop-tone.