upvote
> Your design choice went from a Postgres design pattern to a Mysql one. The difference is the reindexing cost vs the lookup cost - Postgres optimized for lookup and Mysql does for indexing on writes. Or more accurately, Postgres was better with good schema design using joins & mysql was optimized for a bad design with less normalization where many indexes exist for the same table

You are right that MySQL does better when you have lots of indexes, but I don't think the tradeoff is that the overall Postgres architecture is better with good schema design.

Having secondary indexes point the primary key enables things like undo logging, which obviates the need for vacuums - vacuums being the most painful part of Postgres. On top of that your primary key index will be mostly cached so the cost of the indirection is much smaller than it may first appear

reply
I think OP is just alluding to the fact that Postgres needs to do less work to go from secondary index to table data, since the tid is a direct pointer to the exact page and slotted entry while MySQL needs a b-tree walk.

> primary key index will be mostly cached so the cost of the indirection is much smaller than it may first appear

Not sure I follow. If it's in-memory you save having to read from disk, but you still have to walk the b-tree to go from PK to data.

reply
MySQL was generally (pre 8) optimized for point queries on primary keys. So rows are stored in the PK index, the PK index is a clustered index. Everything more or less falls out of this.
reply
> mysql was optimized for a bad design

TIL I should have been using mysql the whole time

reply
Richard Gabriel's "Worse is better" vibes.
reply
I find it amusing people started quoting LLM output and are responding to it. Hopefully the original authors end up having the LLM respond back.
reply
Many of the commenters on this site are also obviously LLMs. I'd imagine that quite a few of the entities quoting aren't necessarily people. Keep an eye on where they slide mentions of other products that a marketing team would like to promote.
reply
Personally I haven't seen it too often; the other aspect is that HN is a forum for startups to pitch shit to each other, so this has been happening with or without marketers (f.e. "i'm working on a similar thing").

That LLMs are taking over the comments section is something that was already flagged, and Lobste.rs and others have started solving it by having gated registrations. HN should do this but it is unlikely to until it is too late.

reply
I don’t get it though… what’s the point of using an LLM just to comment here? Like what does it gain the person doing it
reply
Sorry, how does a gated registration stop someone creating an account, then handing it over to an LLM?

Serious question, am I misreading what's being said?

reply
It stops the automation part. One LLM spammer can be dealt with.
reply
One can focus on generating 10 other accounts before it's flagged. Now you have 10 others to deal with.
reply
But that does not work on lobsters (or anywhere else with gated registration), because you cannot just create 10 accounts. You can create 1 account after 1 invite. If you abuse, you loose the invite (and maybe the person inviting you the right to invite others).
reply
lobste.rs has always been invite-only.
reply
MSSQL (Clustered Indexes) and Oracle (Index Organized Tables) among others let you chose because there are advantages and disadvantages for different situations.

Not having true clustered indexes in PG is something I miss coming from MSSQL, it helps performance when the majority of access is always primary index avoid indirection from index lookup then tuple lookup and it also saves space if its the only index.

reply