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

101–105 of 105 posts

Re: MySQL 8.0 is now generally available

#101

Post by ptman »

marcosdumay wrote: post #86
greenhouse_gas wrote: post #83

Earlier quoted context omitted.

I'm not a DBA, and it could very well be that it's because I'm coming from the LAMP world, but when I need something light and simple, MySQL or MariaDB fit the bill a lot more than Postgres. In MySQL there are five steps: Install MySQL (creating root user at the same time), CREATE DATABASE X, USE DATABASE X, CREATE table Y, work. If I need something more secure, I'll add a "Create User"/add permissions step in there.…

Install Postgres; `su postgres` or whatever user it uses; run `psql`; `CREATE USER X IDENTIFIED BY PASSWORD;` `CREATE DATABASE X OWNER X;' Now X can connect there and add tables as he wishes. Postgres onboarding coule be better, but it is naive to choose a tool you will use for years based on the first 5 minutes experience.

    \help CREATE USER

    \help CREATE DATABASE

Re: MySQL 8.0 is now generally available

#102

Post by evanelias »

zht wrote: post #100
mfjordvald wrote: post #89

Earlier quoted context omitted.

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?

Without a WHERE clause, select count(*) still does a full table scan (or full index scan) in InnoDB, and probably always will.

It is optimized in MyISAM via table-level metadata, which is only possible because MyISAM doesn't use MVCC or support transactions.

In InnoDB, you can get an estimated row count from SHOW TABLE STATUS, but the estimate is based on table stats and can be wildly inaccurate.

Re: MySQL 8.0 is now generally available

#103

Post by evanelias »

sjwright wrote: post #95
evanelias wrote: post #73

Earlier quoted context omitted.

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.)

Fair enough, but personally I would be very hesitant to adopt TokuDB for a new use-case in 2018. Its rate of development and adoption have both slowed considerably in recent years, and MyRocks covers similar use-cases.

Re: MySQL 8.0 is now generally available

#104

Post by karmakaze »

kbsletten wrote: post #63
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…

I have to say, I wouldn't get your hopes up. If I were MySQL, I wouldn't touch this with a 10 ft pole because it's not likely to really affect somebody's opinion of MySQL enough to switch, but there's going to be at least one person whose code you'll break. Before you can consider SQL compatibility, you have to keep most-popular-version-of-mysql compatibility.

I don't see the problem here. Make the default preserve backward compatibility, but offer an option like 'SIMULTANEOUS_ASSIGNMENT' to be standards-compliant.

Re: MySQL 8.0 is now generally available

#105

Post by th3sly »

sjwright wrote: post #93
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.

> 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 o…

regarding query plan visualizer, workbench has added one in recent years: https://dev.mysql.com/doc/workbench/en/wb-performance-explai...
Post reply on HN