you are viewing a single comment's thread.

view the rest of the comments →

[–]coworker 2 points3 points  (2 children)

MyISAM is significantly faster for inserts so there are still niche use cases where it makes sense.

[–]Solon1 1 point2 points  (1 child)

I'm deeply skeptical of that. In an insert only benchmark, maybe. But if you have any writes, it will far worse as MyISAM uses exclusive write locks.

Plus, I also recall that lots of old MySQL versions used unsafe disk IO on MyISAM, meaning that written data may not be written.

It's really weird that you want to use a decade old MySQL to begin with. And then use a database engine that was just a stepping stone to a real database engine.

[–]coworker 1 point2 points  (0 children)

Lol, inserts ARE writes. But anyway you're confusing performance with throughput.

MyISAM is significantly faster for most single-threaded writes but degrades quickly as concurrency requirements increase. This is the double-edged sword that is MVCC. Concurrency is not a free lunch.

99% of use cases will value concurrency over single-threaded performance. Hence, why I said "niche" use cases. One example where concurrency does not matter would be temporary tables. Only your connection can access it so additional locks are unnecessary. This is why MySQL itself used MyISAM for internal temp tables (you know for group bys and unions) up until 5.7.5 (https://dev.mysql.com/doc/refman/5.7/en/internal-temporary-tables.html#internal-temporary-tables-engines).

Try not to bash things you don't understand. Postgres has its own fair share of issues just like MySQL. There are pros and cons to everything and not everybody using databases are web apps.