Live data from Hacker News

Can PostgreSQL pickup where MySQL left off?

news.cnet.com

41–46 of 46 posts

Re: Can PostgreSQL pickup where MySQL left off?

#41
post #13
post #4

I wonder why MySQL became super-popular and Postgres didn't. I remember reading for years about how Postgres had a bunch of stuff (e.g. transactions) that MySQL didn't (until recently) and that anybody who knew anything about databases would choose Postgres, yet people still chose MySQL. What did MySQL have during the last decade that made it better for certain applications than Postgres?

MySQL is a triumph of branding and fanboy self-delusion. MySQL made it easier initially by omitting lots of difficult stuff (data integrity, management, transactions) thus making easier to get something working quickly. It also had a reputation for being faster then PostgreSQL, a reputation spread by fanboys (in truth people who were bigging up the only database they had a faint comprehension of). Then it became ubiq…

> MySQL made it easier initially by omitting lots of difficult stuff (data integrity, management, transactions) thus making easier to get something working quickly.

Remind anyone of NoSQL? :)

Re: Can PostgreSQL pickup where MySQL left off?

#42
In my mind, replication has historically been a pretty big deciding factor in favor of MySQL. PostgreSQL didn't support it natively until version 9.0 (which still isn't part of most Linux distro repositories). You'd have to install Slony or something similar. MySQL made master/slave or master/master replication simple to configure and a breeze to maintain.

Re: Can PostgreSQL pickup where MySQL left off?

#43
post #37

Earlier quoted context omitted.

> 2) There was an effective row size limit of 8K over the whole row which worked against people who wrote forum software and were (ugh) storing binaries in the database. Could you not just use the dedicated TEXT or BLOB type for that kind of stuff, and store them out-of-row? (yes, would probably have been even slower)

Nope. There was blob-support, but that relied on special library functions to extract the data to a file which you'd then have to manually read. Of course this also means that you couldn't search in these fields or do anything else you'd do directly on the database. TOAST tables were added in 7.1 AFAIK which lifted that limit and allowed for arbitrary sized rows by moving the big fields away into their own storage. T…

> Nope. There was blob-support, but that relied on special library functions to extract the data to a file which you'd then have to manually read.

OK.

> The old functionality is still there (http://www.postgresql.org/docs/9.0/interactive/largeobjects....) though I totally failed and still fail to see any practical use.

Memory constraints maybe? That's about the only justification I could see for using that over bytea: if you store single binary objects in the GB+ range, you may want to interact with them as streams.

Re: Can PostgreSQL pickup where MySQL left off?

#44
post #40

Earlier quoted context omitted.

#2 - even if you don't store binaries, just very long posts, it's a problem. #4 - whether it's a misconception or not, the majority of tutorials and even the default utilities make that assumption. Working around that is not something as widely documented as the defaults. Also, forum software is a big arena. Not being able to get accurate count() values back hurt(s) postgresql. It's hurting people who now rely on MyS…

> I don't ever recall hearing about the "embedded linkable and serverless variant" of MySQL, and have been doing PHP since 1996. Perhaps it was a licensing issue? http://dev.mysql.com/doc/refman/5.1/en/libmysqld.html pretty much a licensing issue as all of MySQL is released under the GPL or a proprietary license. This also includes the mysql client by the way, but they made a license exception there that allowed link…

re: count() - I guess I should have also said "reasonably fast". Waiting 8 seconds for a count() isn't practical for many apps.

Re: Can PostgreSQL pickup where MySQL left off?

#45

Earlier quoted context omitted.

#2 - even if you don't store binaries, just very long posts, it's a problem. #4 - whether it's a misconception or not, the majority of tutorials and even the default utilities make that assumption. Working around that is not something as widely documented as the defaults. Also, forum software is a big arena. Not being able to get accurate count() values back hurt(s) postgresql. It's hurting people who now rely on MyS…

Under what circumstances is count() inaccurate in Postgres?

See earlier comment - I misstated my point - it's not so much that it's inaccurate as slow. Dog slow. InnoDB in MySQL 'fixes' the speed with estimates, but that's generally not very useful either in most cases (sometimes, it is).

I was confusing my earlier innodb count() experiences (inaccurate estimates) with postgresql count() experiences (dog slow).

Re: Can PostgreSQL pickup where MySQL left off?

#46
post #3

IMO the short answer is: no. Most opensource software that uses MySQL is riddled with MySQLisms.

Many forks exists to deal with this situation http://en.wikipedia.org/wiki/MySQL#Forks

You don't need fork for that — just enable ANSI mode.

The problem is that MySQL-based software doesn't do that and relies on the default "quirks" mode.

Post reply on HN