On Wednesday 11 October 2017 15:09:49 Steven Lembark wrote: > > > It is not as easy as it could appear. And also in some cases migration > > from MySQL/MariaDB to Pg could be problematic from performance point of > > view. One Pg developer already told us that for our use case is really > > MySQL better then Pg. > > Q: What about your use case is more adapted to MySQL? > > There is no part of SQL that Pg does not support that MySQL does; there > should not be any serious performance issues with Pg that leave it > slower than MySQL. There are a variety of ways that Pg can be faster > (e.g., partial indexes, exclusion constraints vs. triggers) and will > usually be less error-prone. You may have to refactor some sloppy design > that MySQL allowed but Pg does not, but that is also in your favor. > > I really am curious to see any example of something in your database that > can be handled more gracefully in MySQL than well-designed Pg.
Hi! The use case is massive updates of existing columns in huge table. Updates of columns in Pg are done just in linked-list until autovacuum cleanups older values. If there are too many updates, then select queries are slower. I do not know if new version of Pg have better performance for such use case, but year (or two?) I was told that by Pg developer that for such usage is MySQL still better.
