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.
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!
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.
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.
PS: I do use LLM for polish, etc.
- 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.
EDIT: And you can read for yourself how the LLM rates these two paragraphs compared to each other: https://chatgpt.com/share/6a6a3120-fec4-83eb-9c8b-dbb6294aa5...
It's not a human way to think, talk or write.
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.
"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"
Please, write your own prose.
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.
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.