Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MySQL 8.0 is now generally available

mysqlserverteam.com

Post reply on HN
Print view View original

91–100 of 105 posts

Re: MySQL 8.0 is now generally available

#91

Post by beberlei »

zht wrote: post #80
rogerdpack wrote: post #78

Earlier quoted context omitted.

I've had count(*) queries take like literally days in Postgres. Want to insert a lot of data? Expect it to cost a lot of RAM. It's got high features but some really rough edges too :|

the same would happen in MySQL right? select count(*) does a table scan

Depends on the storage engine afair, but both innodb an myisam have either index or global metadata based solution for this. I think in myisam its an estimste if you use count(*) so you need to use count(id) to get an exact value. This is all well documented

Re: MySQL 8.0 is now generally available

#92

Post by PeterMikhailov »

gtowey wrote: post #75
ayan wrote: post #58

Earlier quoted context omitted.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

This covers probably the most important reasons to use MySQL over PostgreSQL: https://eng.uber.com/mysql-migration/ The TL;DR is that PostgreSQL on-disk storage format leads to much higher IOPs for the same workload. For companies running OLTP at scale, the cost differences can be huge.

I've been to a few talks from the PostgreSQL lead developers where they mention this.

Their opinion was mostly "Uber could have just asked us the right way to do it" and "We believe Uber's new engineering leader needed something to do"

Re: MySQL 8.0 is now generally available

#93

Post by sjwright »

ayan wrote: post #58
dancek wrote: post #2

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago. Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

> why, in a world where PostgreSQL exists, would anyone use MySQL.

You could also ask why would anyone use Postgres? Either question is equally absurd. If MySQL and its forks work well enough for Google, Facebook, Uber, AirBNB, Alibaba and Linkedin, why should anyone take it on face value that Postgres is an unambiguously better choice?

That said I've toyed with switching in the past. Ten years ago, the MySQL query optimiser was fairly junk and I wanted to switch for that alone.[1] The main thing that held me back was that my application has hundreds—quite probably thousands—of SQL queries coded into it.

Despite "SQL" being a notional standard, even the most basic queries would need to be extensively reformatted to be compatible with Postgres. The effort required to rewrite all of these queries simply can't be justified, particularly because we simply don't have any problems with MariaDB. The query optimiser is a lot better now, such that I now rarely encounter situations where a sensible query doesn't yield an efficient execution plan.

[1] Between 2000 and 2007 I had spent a lot of time with MSSQL for a different project and I had grown to appreciate its excellent query optimiser and execution plan visualiser. Ten years on and I still haven't seen any F/OSS solution that does as good a job as SQL Server 2000 in this regard. The most recent version I've used is 2005 so it might be even better today. And believe me, I was not a fan of Microsoft in the 2000s.

Re: MySQL 8.0 is now generally available

#94

Post by userbinator »

tzs wrote: post #53

I had hoped that the SQL improvements would fix this annoyance, but according to the documentation they did not: create table fib ( a integer, b integer ); insert into fib (a, b) values (1, 0); update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; update fib set a=a+b, b=a; select a, b from fib; The correct result according to the SQL standard is a == 8 and b == 5…

Simpler example:

https://bugs.mysql.com/bug.php?id=13943

Reported over 12 years ago...

Re: MySQL 8.0 is now generally available

#95

Post by sjwright »

evanelias wrote: post #73
ayan wrote: post #58

Earlier quoted context omitted.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

MySQL is still a perfectly reasonable choice for massive-scale OLTP workloads. In my mind, a few things MySQL excels at: * Threaded connection model. Postgres still uses process-per-conn right? This is very painful in situations with high connection churn / fire-and-forget db conns, which are required in some circumstances (heavily sharded environments where keeping persistent connection pools between all app servers…

And don't forget the TokuDB storage engine. It has some very interesting and different scaling/performance characteristics which can provide dramatic improvements for some workloads.

(Even though TokuDB is probably not the "best" choice for my workload, I love it for my text-heavy tables because its performance is still great and its on-disk compression ratios are superb.)

Re: MySQL 8.0 is now generally available

#96

Post by sjwright »

petre wrote: post #87
dancek wrote: post #2

There are some very useful features there, but I can't help but think that MySQL should have had them a long time ago. Is there something MariaDB doesn't have? I'm genuinely curious as I've only really followed PostgreSQL development.

> Is there something MariaDB doesn't have? * Proper native JSON support * Spatial support lags behind MySQL However we are still using it in production and MySQL 8 is a no go given that it removed MyISAM support. We still use MyISAM due to fast inserts and easy backup (just copy the files). We use MariaDB for storing IoT time series data.

Have you explored the TokuDB storage engine? Or Aria?

Re: MySQL 8.0 is now generally available

#97

Post by sjwright »

dpcx wrote: post #35
giancarlostoro wrote: post #9

Earlier quoted context omitted.

People are going to start to think tech companies don't know how to count or something. Jokes aside... I'm wondering the same.

"start to think" ? Microsoft went from Windows 2000 to Windows XP then to Vista and then to 7. If people haven't already been thinking that, this isn't what's going to start it, IMHO.

...Xbox, Xbox 360, Xbox One...

Re: MySQL 8.0 is now generally available

#98

Post by petre »

sjwright wrote: post #96
petre wrote: post #87

Earlier quoted context omitted.

> Is there something MariaDB doesn't have? * Proper native JSON support * Spatial support lags behind MySQL However we are still using it in production and MySQL 8 is a no go given that it removed MyISAM support. We still use MyISAM due to fast inserts and easy backup (just copy the files). We use MariaDB for storing IoT time series data.

Have you explored the TokuDB storage engine? Or Aria?

Yes. Aria is one of the reasons we are using MariaDB in fact. It offers a great migration path from MyISAM. We migrated from MySQL 4.6, that's why our tables are in fact MyISAM. We currently have a test server running using Aria tables.

I have also thought about using TokuDB but SuSE (13.2) didn't ship a module for it then. I have to check again in 42.3.

The only real issues with MariaDB is lack of proper JSON and spatial support which would be of great use to us. I'm talking about a real JSON data type with validation and means to query and maybe even replace JSON, not a mere alias for the LONGTEXT data type.

We intend to switch to Postgres on the long run. It has everything we want, moreso with TimescaleDB extensions which could proove very useful for storing time series data. We are currently using it for the spatial database.

Re: MySQL 8.0 is now generally available

#99

Post by ptman »

gaius wrote: post #61
ayan wrote: post #58

Earlier quoted context omitted.

I feel the same way. I've been using and tracking both since the mid to late 90s. I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL. New releases seems to only slightly close the gap between it and better RDBMSs while retaining quite a few kludges and ambiguities. In the meantime PostgreSQL gets better at the same pace.

I've always wondering why, in a world where PostgreSQL exists, would anyone use MySQL I am a solid Postgres guy, but MySQL still has a better multi-master replication story. Confident that Postgres will eventually surpass it, possibly even in a later iteration of 10. Now in a world where Postgres exists why would anyone use MongoDB is a valid question...

Postgres 11? Postgres 10 will only get bug fixes.

The version numbering was changed with 10

Re: MySQL 8.0 is now generally available

#100

Post by zht »

mfjordvald wrote: post #89
zht wrote: post #80

Earlier quoted context omitted.

the same would happen in MySQL right? select count(*) does a table scan

count(*) doesn't do full table scan as it's not tied to specific data. It has special handling logic. The only case where it might have to do a full table scan is if you try to count() on a specific (nullable?) column without an index.

I've always had select count(*) do a full table scan (or at least take considerable time) in innodb... Did something change?
Post reply on HN