Postgres Engine for MySQL Released

SlashRating©
11.9
slashdottit! tm

krow writes "One of the unique qualities of the MySQL server is its ability to have multiple storage engine operate concurrently. Companies like Oracle and Solid have contributed their own storage engines to the open source project. With 5.1 MySQL has added the ability to now do this in a loadable fashion, allowing dynamic engines in the same manner as Apache with its modules. Now PostgreSQL can add its self to the list of databases who have contributed a storage engine to MySQL. I'm releasing today a plugin so that you can now plugin the Postgres database engine into MySQL and have it work natively along side other engines."

Can't hold my breath...

[Epaminondas Pantulis]

till they release a DBase III engine...

SQL Server Engine?

[Zebra1024]

This would have been a better joke if it was Microsoft adding a SQL Server engine.

MySQL teh suck?

[Urusai]

I thought with MySQL going all corporate and proprietary-like, the bandwagon was jumping ship. MySQL always sucked anyway, unless you were operating a flat file type database. In conclusion, quit swinging on MySQL's nuts. Thank you.

Re:Seriously though...can someone explain it

[Just Some Guy]

can someone give a quick summary as to why this is hilarious and people are currently LOL

Have you ever laughed at a hopped-up Dodge Neon with a whale tail and three rows of headlights? Well, imagine that the owner had found managed to buy a Ferrari, rip its engine out, and install it in the Dodge. It would be an interesting hack, but why not just drive the Ferrari in the first place?

Re:MySQL teh suck?

[isorox]

The only ways mysql gets into corporate machine are
1) Grass roots simply installing it
2) Snr Mgmt being dazzled by golf and wine weekends

I can get my techliterate boss to point to a costly Mysql enterprise support package in those high up meetings where nothing really gets decided, but decisions float down from, and we are fine to dump Oracle for the latest 2000 queries/day intranet site.

In reality the support will be mostly Usenet, but it keeps the suits happy knowing that it must be good because it has a corporation selling it.

I can then arrange a junket to a mysql training course in some exotic country to teach something that could easily be learnt from online docs, but is ammo to go into bat with with suppliers that sold us a painful system to work with (load data from master on a database with 500MB of indexes and several updates per second is not a great way to ensure uptime, but they won't even entertain the idea of a mysql cluster at the moment. This "system" caused me 2 hours of grief this morning (fortunatly experience suggested that we'd need extended downtime).

Re:should speed up Postgresql

[Master of Transhuman]

PostgreSQL is LESS capable than MySQL? (Slower at some things, maybe, but LESS CAPABLE?)

Leave the crack pipe at home next time.

Re:When to use then vs. Than

[Master of Transhuman]

"of all nations America is the one that has traditionally been a haven for immigrants from all cultures"

The operative word here is "traditionally".

Once the immigrants got here, they immediately began discriminating against NEWER immigrants. Look at the histories of the Irish, the Italians, the Poles, the Russians, the Chinese, the Vietnamese, the Middle Easterners, the you-name-it.

That hasn't stopped.

It's human nature - if you're not one of "us" - for no matter how small a set of "us" (down to order 1 for me) - you're bad.

Chimpanzees have better manners.

Re:should speed up Postgresql

[jadavis]

A hack like this that actually worked would let you run crappy open source code on a more scalable database back end.

A lot of PostgreSQL's performance comes from it's cost-based optimizer that chooses the correct plan based on statistically sampling your real data periodically. In other words, as your data changes, your plans change accordingly without administrator intervention. MySQL's optimizer is much more primitive.

Also, PostgreSQL has much more sophisticated options when planning, like bitmap index scans (which can be ANDed/ORed with other indexes and reorder the tuple fetching in disk order), GIN and GiST indexes, Hash Aggregates, Hash Joins, etc.

However, if PostgreSQL were just a "storage engine" I don't MySQL's storage API would pass enough information about the high-level query down to the PostgreSQL storage engine. That means PostgreSQL couldn't make good choices for plans.

A "storage engine" with a simple API for storing/fetching records is fairly uninteresting from a database performance standpoint.

Granted, PostgreSQL's MVCC is likely to be a win under concurrent access in some situations. But the wide range of performance that PostgreSQL delivers without modification of application queries (or administrator intervention) is where it really shines.