On Mon, 25 Apr 2016 21:48:44 -0400, Adam Brusselback
<adambrusselback@gmail.com> wrote:
>>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 could see a true column store having much better performance than
>tricking a row based system into it. Just think of the per-row overhead we
>currently have at 28 bytes per row. Breaking up data manually like that
>may help a little, but if you don't have a very wide table to begin with,
>it could turn out you save next to nothing by doing so. A column store
>wouldn't have this issue, and could potentially have much better
>performance.
A column store must be able to distinguish entries in the column
[which may be non-unique] as well as join the columns of the
fragmented virtual table to reconstruct its rows.
These requirements dictate that a "column" be at least a triple:
{ id, table_row, data }
so there is no space saving WRT row store - the opposite in fact:
column store usually requires more space.
Column store enhances performance mainly by not fetching and not
caching unused data. And standard practices like controlling the
physical locations of tables help both row and column store systems.
George
