4 ms·

> The compromises to make mSQL fast were inherited by MySQL, and they can't be easily changed without breaking the ecosystem that was developed around mSQL/MySQ

> The compromises to make mSQL fast were inherited by MySQL, and they can't be easily changed without breaking the ecosystem that was developed around mSQL/MySQL. This doesn't sound accurate to me. Which compromises are you referring to? Historically, MySQL's major source of criticism related to leniency of type safety / automatic data conversion -- which is unrelated to performance. It's also essentially a solved problem with the advent of strict sql_mode. MySQL made this the default in 2015, but it has been available (and recommended as a best practice) since 2004. Performance in MySQL, as a general topic, greatly depends on the storage engine. Relative to Postgres, MySQL's pluggable storage engine API is both a blessing and a curse -- it permits use of alternative engines that perform significantly better for specific workloads, at the cost of substantial administrative complexity. Performance-wise, Postgres generally has the lead for things like number of supported index types, join strategies, query planning for very large queries (and OLAP workloads in general). These may or may not matter for you, depending on your workload.

marcosdumay 8y ago
The main selling point of MySQL at the earlier 2000's was that it used an in-memory storage with only opportunistic disk writes. That made for an incredibly fast database, with obvious downsides that many people refused to notice.
- evanelias 8y ago
  What storage engine are you referring to? I've been using MySQL since the earlier 2000s, and your description doesn't match MyISAM (which uses the filesystem cache for data blocks, only using its own caching for indexes) nor InnoDB. MyISAM does offer amazing write performance, at the cost of not being crash-safe. But given its reliance on the fs cache, it would be unusual to describe it as "in-memory storage". Anyway, the GP was talking about compromises that "can't be easily changed without breaking the ecosystem", which doesn't describe MyISAM either -- MyISAM is basically deprecated in modern MySQL deployments.

marcosdumay 8y ago

The main selling point of MySQL at the earlier 2000's was that it used an in-memory storage with only opportunistic disk writes. That made for an incredibly fast database, with obvious downsides that many people refused to notice.

evanelias 8y ago
What storage engine are you referring to? I've been using MySQL since the earlier 2000s, and your description doesn't match MyISAM (which uses the filesystem cache for data blocks, only using its own caching for indexes) nor InnoDB. MyISAM does offer amazing write performance, at the cost of not being crash-safe. But given its reliance on the fs cache, it would be unusual to describe it as "in-memory storage". Anyway, the GP was talking about compromises that "can't be easily changed without breaking the ecosystem", which doesn't describe MyISAM either -- MyISAM is basically deprecated in modern MySQL deployments.