On Thu, 21 Apr 2016 09:08:22 -0700, "David G. Johnston" <david.g.johns...@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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
