If you’re retrieving N fields in a row, the base case is N * (the work of retrieving one row), because you have to look in N different places.

Obviously, a big part of columnar DBMS design is figuring out ways to outperform the base case. But absent something like the TransRelational architecture (see the category for same) — or some other major deviation from a simple-minded columnar approach — it’s hard.

That’s for single rows. Once you’re retrieving lots of blocks of data, then the factor can be diminished or go away entirely, and be outweighed by columnar’s inherent advantages (you’re not retrieving the WHOLE row, and compression may work better).

CAM

I’ve read comments (yours and others) about columnar databases being slow to retrieve whole rows; but, I don’t hear anyone saying “how slow”. Can you shed any light on this? Are we talking 10’s or 100’s of milli-seconds … or longer?

And thus you’ve neatly explained why not EVERY ParAccel customer buys Amigo mode.

CAM

I’m confused by the comment that, in Amigo mode, the schema is the same on the OLTP SQL Server and on ParAccel. That seems to be incredibly limiting. Although it might be true for some very simple reporting applications, no data warehouse I’ve ever seen uses the same schema as the OLTP source system. Also, what if there are many source systems (which is the typical case)?

If true, surely this would be unusable in the vast majority of real-world situations.

Stuart