ParAccel actually uses relatively little PostgreSQL code
I often find it hard to write about ParAccel’s technology, for a variety of reasons:
- With occasional exceptions, ParAccel is reluctant to share detailed information.
- With occasional exceptions, ParAccel is reluctant to say anything for attribution.
- In ParAccel’s version of an “agile” development approach, product details keep changing, as do plans and schedules. (The gibe that ParAccel’s product plans are whatever their current sales prospect wants them to be — while of course highly exaggerated — isn’t wholly unfounded.)
- ParAccel has sold very few copies of its products, so it’s hard to get information from third parties.
ParAccel is quick, however, to send email if I post anything about them they think is incorrect.
All that said, I did get careless when I neglected to doublecheck something I already knew. The conclusion of this post isn’t really consistent with what ParAccel told me way back in February, 2007 about how much or how little PostgreSQL code they use in their product. As ParAccel just emailed me — for attribution 🙂 —
Our C-MPP execution engine on our compute nodes is written from scratch from the ground up. There is a thin layer of postgres on the leader node (for parsing, initial planning, ODBC, JDBC), but 90% of the leader is also new code.
I’d guess that’s a lot like how Infobright and Kickfire use MySQL, although I wouldn’t want to commit to exact details. 😉 By way of comparison, PostgreSQL-compatible Vertica actually uses no PostgreSQL code at all, whereas row-based Greenplum and Aster Data make heavy use of PostgreSQL code. DATAllegro (now Microsoft Project Madison) makes heavy use of the underlying row-based general-purpose DBMS. Netezza made some use of PostgreSQL code when it started years ago — but not, I think, to nearly the extent Greenplum and Aster Data did.
Comments
3 Responses to “ParAccel actually uses relatively little PostgreSQL code”
Leave a Reply
I’ve probably carried on about this before, but…
Last I knew Netezza used PG pretty much as-is on the head node to store the data dictionary and other metadata. The actual code that runs on the SPUs is dynamically generated on the fly on the head node, so that can in no way be borrowed from PG. 🙂
Tom,
Good point. 🙂
CAM
[…] my recent blog post, ParAccel is once again angry that I haven’t given it proper credit for it accomplishments. […]