3 ms·

Hmmm, consistently deteriorating performance over time is rather suspicious. A move by Oracle to kill off competition for their implementations? I can only spec

Hmmm, consistently deteriorating performance over time is rather suspicious. A move by Oracle to kill off competition for their implementations? I can only speculate, though. It seems odd, though. I guess it's all PostgreSQL all the time for me, from now on.

lawpoop 9y ago
MariaDB is a thing.
- wcarron 9y ago
  Yeah, but why would I use that over PostgreSQL? I already know postgreSQL and it's also THE gold standard for SQL implementations. AFAIAC PostgreSQL is the obvious choice.
  - lawpoop 9y ago
    You would use it over PostgreSQL because it's a drop-in replacement for MySQL. PostgreSQL is not. If you're not using MySQL in the first place, why would you care?
    - wcarron 9y ago
      Because sometimes I DO use MySQL because a client requested it. At this point, I'll probably just explain to clients why pg is a much better alternative.
      - lawpoop 9y ago
        From a fresh build, I agree with you. However, for MySQL in an existing application, the migration costs might make it not worth it. There can be a number of pernicious gotchas that aren't obvious at first. MariaDB is more or less set-and-forget.
emfree 9y ago
I think the author is specifically evaluating low-concurrency in-memory workloads here. The previous post describes why regressions for those workloads might be "not a surprise": https://smalldatum.blogspot.com/2017/05/the-history-of-low-concurrency.html https://smalldatum.blogspot.com/2017/05/the-history-of-low-c...
- kijin 9y ago
  Yes, it seems that Oracle does care about performance in high-concurrency applications: https://www.mysql.com/why-mysql/benchmarks/ https://www.mysql.com/why-mysql/benchmarks/ Even their own benchmarks show MySQL 5.7 dipping below previous versions at the low end of the concurrency scale.
  - mdcallag 9y ago
    Yes, context is everything when looking at benchmark results. I am showing the worst-case for this performance regression. Thanks for mentioning that. Note, that is my blog. I also showed the impact for IO-bound workloads, and even there the regression is larger than I want. But not as bad as the in-memory workloads.
- lathiat 9y ago
  This context is key here. High concurrency workloads have not suffered this badly and in most cases have increased performance and that's specifically part of why. For many (or possibly even a good majority) of users, that's more important than low-concurrency. Those blindly suggesting MariaDB or Percona is all well and good but naive. Percona generally follows MySQL upstream but makes their own little tweaks which could be (but are not always) fixed in MySQL upstream based on differing specific priorities. MariaDB is highly diverged at this point and likely has a whole different set of problems and benefits. Author of these posts is well known for a long (10+ years) history of working with MySQL at a deep level rivalling that of many of the developers, generally writes good stuff (though is not infallible :)

lawpoop 9y ago

MariaDB is a thing.

wcarron 9y ago
Yeah, but why would I use that over PostgreSQL? I already know postgreSQL and it's also THE gold standard for SQL implementations. AFAIAC PostgreSQL is the obvious choice.
- lawpoop 9y ago
  You would use it over PostgreSQL because it's a drop-in replacement for MySQL. PostgreSQL is not. If you're not using MySQL in the first place, why would you care?
  - wcarron 9y ago
    Because sometimes I DO use MySQL because a client requested it. At this point, I'll probably just explain to clients why pg is a much better alternative.
    - lawpoop 9y ago
      From a fresh build, I agree with you. However, for MySQL in an existing application, the migration costs might make it not worth it. There can be a number of pernicious gotchas that aren't obvious at first. MariaDB is more or less set-and-forget.

emfree 9y ago

I think the author is specifically evaluating low-concurrency in-memory workloads here. The previous post describes why regressions for those workloads might be "not a surprise": https://smalldatum.blogspot.com/2017/05/the-history-of-low-concurrency.html https://smalldatum.blogspot.com/2017/05/the-history-of-low-c...

kijin 9y ago
Yes, it seems that Oracle does care about performance in high-concurrency applications: https://www.mysql.com/why-mysql/benchmarks/ https://www.mysql.com/why-mysql/benchmarks/ Even their own benchmarks show MySQL 5.7 dipping below previous versions at the low end of the concurrency scale.
- mdcallag 9y ago
  Yes, context is everything when looking at benchmark results. I am showing the worst-case for this performance regression. Thanks for mentioning that. Note, that is my blog. I also showed the impact for IO-bound workloads, and even there the regression is larger than I want. But not as bad as the in-memory workloads.
lathiat 9y ago
This context is key here. High concurrency workloads have not suffered this badly and in most cases have increased performance and that's specifically part of why. For many (or possibly even a good majority) of users, that's more important than low-concurrency. Those blindly suggesting MariaDB or Percona is all well and good but naive. Percona generally follows MySQL upstream but makes their own little tweaks which could be (but are not always) fixed in MySQL upstream based on differing specific priorities. MariaDB is highly diverged at this point and likely has a whole different set of problems and benefits. Author of these posts is well known for a long (10+ years) history of working with MySQL at a deep level rivalling that of many of the developers, generally writes good stuff (though is not infallible :)