4 ms·
While that is true and the mysql query cache definitely became a scaling issue as machines got bigger with lock contention etc., postgres doesn't even have a si
by znep 10y ago
While that is true and the mysql query cache definitely became a scaling issue as machines got bigger with lock contention etc., postgres doesn't even have a similar feature period.
Suppose you have a query that is doing a group by on a low cardinality field (eg. state) on a hundred million row table. Large amount of data in, small amount out. postgres has to actually look at all the rows to re-run the query. The mysql query cache only has to pull the tiny number of results out of the cache for that specific query.
This is a dangerous feature because there is a super slippery slope as traffic increases... any change to any of the tables invalidates the cache when you need caching most, and hits all queries against those tables at the same time. But if used well in an environment with many copies of the data (replicated or otherwise) where you could manage when updates happened, it can be a lifesaver.
InnoDB also has its own buffer pool that caches rows and is in general terms similar to the postgres buffer cache.
It is fair to say that mysql has a lot more features like this that are "sometimes life-saving hacks that can bite you hard if you don't understand them" and postgres is much more restrained in ensuring the features are a little more general and thought through.
- brianwawok 10y agoMySQL needs the cache more often though with a limit of one index per query. Postgres seems like it more often can combine a few indexes and turn what scans 100k rows in MySQL into bitmasking two indexes and pulling 10 rows. Seems sensible, each has features to support the base design.
- znep 10y agoTrue point (disclaimer: don't know how mysql has evolved in the past 5 years). Fits with my general feeling of "if you want to optimize for a super specific use case, sometimes mysql can provide some cool tricks for that use case that can be amazing" but if you want a more general solution if you need more flexibility or don't have the knowledge or don't know your future needs, postgres shines.
- morgo 10y agoThe limit of one index per query was lifted in 2005, with mysql 5.0.
- brianwawok 10y agoIt's now one per table. Poor word choice by me, sorry.
- morgo 10y agohttps://dev.mysql.com/doc/refman/5.5/en/index-merge-optimization.html https://dev.mysql.com/doc/refman/5.5/en/index-merge-optimiza...
- jorgeleo 10y ago"While that is true and the mysql query cache definitely became a scaling issue as machines got bigger with lock contention etc., postgres doesn't even have a similar feature period." I am sorry, but I rather not have a feature than having a feature that is questionably implemented.
- maxlybbert 10y agoA few years ago, PostgreSQL added a feature where if (1) you ran a query (and there was no "order by" clause); and (2) before it finished, you started an identical query, the second query would simply piggyback off of the first -- until the first finished. After the original query finishes, the second query will retrieve any rows it missed. When they added this optimization, they issued a warning about it, because identical queries without "order by" clauses will return the same results, but without a guarantee of how they're sorted.