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

81–90 of 105 posts

Re: MySQL 8.0 is now generally available

#81

Post by lstamour »

nik736 wrote: post #65
greenhouse_gas wrote: post #62

Earlier quoted context omitted.

1. LAMP - If you're working with shared hosting, there isn't much of a choice. 2. WordPress. 3. If you need something simple and basic, MySQL is much easier to get up and running.

I agree with 1 and 2 but I don't understand 3. Can you please elaborate?

Biggest difference for me is that MySQL always pushed a simpler user structure while most *nix Postgres packages prefer having corresponding native OS users by default (PAM vs password auth). Also, it always seemed easier to migrate/upgrade MySQL data folders compared to Postgres ones. The specifics aren’t coming to mind right now, though. Finally I know way too many folks who prefer phpMyAdmin, especially when provided from their cheap shared hosting provider.

Don’t get me wrong, I prefer Postgres generally too, but I can definitely see wins to MySQL on ease-of-use. Especially the less standard but more forgiving SQL syntax and simple DESCRIBE commands. Yes the quirks add up for MySQL but Postgres has its share of quirks too.

Re: MySQL 8.0 is now generally available

#82

Post by deathanatos »

theptip wrote: post #22
semiquaver wrote: post #4

> Reliability: DDL statements have become atomic and crash safe, meta-data is stored in a single, transactional data dictionary. Powered by InnoDB! To clarify, does this mean that DDL is now fully transactional the way it is in postgres?

This would be great if so, but it doesn't look like it: https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html > DDL statements, atomic or otherwise, implicitly end any transaction that is active in the current session, as if you had done a COMMIT before executing the statement. This means that DDL statements cannot be performed within another transaction, within transaction control statements such as START TRANSACT…

> DDL statements, atomic or otherwise, implicitly end any transaction that is active in the current session, as if you had done a COMMIT before executing the statement.

That sounds horrifying. Implicitly committing transactions could very well leave the database in an undefined / inconsistent state, no? That is, from the applications view, if I do:

   BEGIN;
     STATEMENT A;
     STATEMENT B;
   END;
I would expect either both or neither to succeed, but that paragraph would suggest that A could succeed, and the transaction be committed. (And who knows after that?)

Am I missing something?

Re: MySQL 8.0 is now generally available

#83

Post by greenhouse_gas »

nik736 wrote: post #65
greenhouse_gas wrote: post #62

Earlier quoted context omitted.

1. LAMP - If you're working with shared hosting, there isn't much of a choice. 2. WordPress. 3. If you need something simple and basic, MySQL is much easier to get up and running.

I agree with 1 and 2 but I don't understand 3. Can you please elaborate?

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.

For some reason, step 2-4 (create user and set up database/table) give me a headache in Postgres.

Re: MySQL 8.0 is now generally available

#84

Post by greenhouse_gas »

collinmanderson wrote: post #79
greenhouse_gas wrote: post #64

Earlier quoted context omitted.

You forgot (especially you're counting consumer Windows, and 2000 was Server windows) 3.1 -> 95 -> 98 (OK. That was normal) -> ME -> XP -> Vista -> 7 (Which should have been 9 If I counted correctly) -> 8 (another OK count) -> 10 -> ? (I don't remember all the Windows 10 releases)

FYI, There always have been actual version numbers under the hood. They kind of messed up 7's number. I guess they had so much trouble changing things from 5.1 to 6.0, they decided another major version bump would be problematic. They apparently changed their minds with 10. 3.10 - 3.1 4.00 - 95 4.10 - 98 4.90 - ME NT 5.0 - 2000 NT 5.1 - XP NT 6.0 - Vista NT 6.1 - 7 NT 6.2 - 8 NT 10.0 - 10 https://en.wikipedia.org/wik…

Thinking about it, codebase-wise XP came from 2000 which came from NT4, which could be why 2000 became 6.

Re: MySQL 8.0 is now generally available

#85

Post by youseecomrade »

greenhouse_gas wrote: post #83
nik736 wrote: post #65

Earlier quoted context omitted.

I agree with 1 and 2 but I don't understand 3. Can you please elaborate?

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

Sounds like Postgres could use some initiative to make the experience easier/faster for beginners and new deployments (if popularity is something valuable for them). That's what many people value in MySQL apart from the familiarity.

I rarely come across tutorials for beginners where MySQL isn't treated like the only option, even if only by omission. I wouldn't be surprised if students only found out about the viability of different databases after a few years.

Re: MySQL 8.0 is now generally available

#86

Post by marcosdumay »

greenhouse_gas wrote: post #83
nik736 wrote: post #65

Earlier quoted context omitted.

I agree with 1 and 2 but I don't understand 3. Can you please elaborate?

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.

Re: MySQL 8.0 is now generally available

#87

Post by petre »

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.

Re: MySQL 8.0 is now generally available

#88

Post by marcosdumay »

deathanatos wrote: post #82
theptip wrote: post #22

Earlier quoted context omitted.

This would be great if so, but it doesn't look like it: https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html > DDL statements, atomic or otherwise, implicitly end any transaction that is active in the current session, as if you had done a COMMIT before executing the statement. This means that DDL statements cannot be performed within another transaction, within transaction control statements such as START TRANSACT…

> DDL statements, atomic or otherwise, implicitly end any transaction that is active in the current session, as if you had done a COMMIT before executing the statement. That sounds horrifying. Implicitly committing transactions could very well leave the database in an undefined / inconsistent state, no? That is, from the applications view, if I do: BEGIN; STATEMENT A; STATEMENT B; END; I would expect either both or n…

> That sounds horrifying.

That means any previous version could fail during DDL execution and leave your metadata in an inconsistent state that you couldn't recover.

Now MySQL is about as good as any commercial database.

Re: MySQL 8.0 is now generally available

#89

Post by mfjordvald »

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

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.

Re: MySQL 8.0 is now generally available

#90

Post by mgkimsal »

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.

CREATE USER X IDENTIFIED BY PASSWORD

Googled that and not one result on the first page mentioned PostgreSQL. I don't think this approach is a common one at all. More to the point, I'm not sure i've ever seen that set of instructions anywhere, ever, for pgsql. Every tutorial and intro focuses on running 'createuser'.

Oh, yeah, and you'll need to be root to go in and futz with your pg_hba.conf file, then have permissions to write it out and restart the server (probably as root).

This 'createuser' approach hasn't been a '5 minute experience' - it's been the approach that is promoted as the default answer/approach almost everywhere I've ever looked for several years.

Post reply on HN