Astor Data, Greenplum and GridSQL all allow Massive Parallel Processing of SQL queries. They are also all built around PostgreSQL technology. Is this just because of licensing issues or are there other reasons? To me, it seems like the MyISAM, not being ACID complient and therefore not running into the same issues with MVCC (like seen here) as PostgreSQL is far better suited for building high-performance data warehouses. After all OLAP load does not require transactions as far as I can see.
It is mostly a license issue. These developments end up patching the code quite heavily, so if you were to deal with MySQL, you'd either have to open-source your code or be at the mercy of MySQL's corporate owner for the life of your business. Some offers for MySQL get around that by implementing their work as a storage engine, but that doesn't offer all the flexibility that they need, and they invariably end up patching the MySQL core as well.
I can see two reasons:
1) historically, PostgreSQL had better query planner and statistics analyzer. This might be not true now, but few years ago PostgreSQL was much better then MySQL on complex queries, which is OLAP ones.
2) PostgreSQL have better functions/triggers/etc programming support.
As Peter Eisentraut correctly pointed out, first and foremost it's a licensing issue. Postgres is licensed under a BSD-like agreement, which makes it essentially a "free for all", so long as you credit the original developers in your derivative work.
The MVCC vs. locking scheduler debate has been the subject of more than a few 'holy wars' online. The debates over the merits of various storage engines have been equally controversial.
The merits of different row-major (aka row-store) storage engines are IMHO largely irrelevant when it comes to MPP RDBMS built for analytic workloads for two reasons:
- While peculiarities of the storage engine are important for processing ACID transactions in OLTP-type workloads, in a typical data warehousing environment, you need to support only one type of "transaction" - a batch load. Ideally it's the batch load that should either succeed entirely or fail completely.
- Analytic databases, based on column-store storage engines, will in many cases outperform any row-store implementation. Vertica was a column store from the start, Teradata and Greenplum recently added column-store functionality to their products.
I built an MPP system on MySQL and I discarded the system for two reasons:
1) is Oracle
2) is the lack of hash joins - nested loop and index joins do not scale to the level required in a MPP system - again because Oracle inhibited the promised delivery of hash joins in the 5.x code line after it took ownership.
MPP big data systems must have joins that are not of geometric complexity. - Linear or log linear complexity joins must be a strong preference for true big data systems.
I deployed Actian vectorwise instead in the new DeepCloud MPP system while maintaining a drizzle/MySQL compatibility at the user level.
Users wanting fast big-data analytics can download DeepCloud from http://www.deepcloud.co