On Thu, 21 Apr 2016 09:08:22 -0700, "David G. Johnston"
<david.g.johnston@gmail.com> wrote:
>?I have little experience (and nothing practical) with columnar store but
>at a high level I don't see the point.
At the high level, it's about avoiding fetching data you don't need.
In a row store system, in general you must fetch the whole row to
extract any of its columns.
It is not difficult to simulate column store in a row store system if
you're willing to decompose your tables into (what is essentially)
BCNF fragments. It simply is laborious for designers and programmers.
>I would hope that anyone interested in working on a columnar store
>database would pick an existing one to improve rather than converting
>a very successful row store database into one.
+1
>And I don't immediately understand how a dual setup would even be
>viable - it seems like you'd have to re-write so much
>?of the code the only thing left would be the SQL parser.
If you are willing to go to BCNF and manage the physical location of
your tables [which any performance system will be doing anyway], then
any decent row store system can mix in "column" tables where desired.
IMO, the only real added value of a dedicated column store system is
to developers: the automagic table fragmentation and the ability to
query virtual tables rather than specify table fragments individually.
Convenient, but not necessary.
YMMV,
George