原文链接：http://www.dbms2.com/2009/08/04/pax-analytica-row-and-column-stores-begin-to-come-together/
实际上，列存储的支持者倾向于争辩说，使用基于行的存储实现分析DBMS的唯一原因是懒惰。他们的案例通常沿着以下步骤运行：
1、 分析查询通常只返回所有可能列的一小部分。
2、 仅返回所需的列
- 保存 I/O
- 节省缓存空间
- 减少处理
- 促进压缩
3、据推测，所有这些基于行的MPP供应商都只是基于行，因为他们有一个很好的基于行的DBMS（通常但并不总是PostgreSQL）可以构建。
基于行的供应商对此论点的反驳包括：
- 是的，但更新列存储更难
- 是的，但是检索一堆列的步骤比从行存储中检索相同信息的步骤更多
不太激烈的言论：
- 我们做得很好，谢谢
- 我们在市场上没有看到太多的列商店
- 不要相信所有的学术炒作
但是，行存储和列存储开始结合在一起的方式至少有两种。首先，有很多关于行存储供应商推出列存储选项的传言，甚至超出了最近的 Ingres/VectorWise 公告。其次，列存储供应商 Vertica 和 VectorWise 正在推出一种行/列混合存储选项。
Vertica 3.5 引入了 Vertica 所称的“FlexStore”。 FlexStore 的一个关键部分是不仅能够以纯列格式存储数据，而且能够以相当于子行的方式将列组合在一起。这在一起检索数据时是有利的，我想在更新数据时也是如此。然而，放弃列存储的压缩优势是有代价的，对于经常独立检索的列，不建议使用此功能。 Vertica 还指出，由于它通常使用 1 兆字节的块大小，因此任何小于该大小的表都不应该被分成列。
当然，VectorWise 目前还没有产品，但最近围绕它计划在 2010 年通过其合作伙伴 Ingres 推出的列存储产品有一系列宣传。当我向 Peter Boncz 询问内部行/列混合时VectorWise（不是 Ingres 和 VectorWise 之间的联合，而是真正在 VectorWise 内部），他说其中一个存储选项是 PAX，并指出我在 2001 年由一群学者撰写的论文，其中包括无处不在的 Dave DeWitt。在创造性的拼写中，PAX 最终代表 Partition Attributes Across。
PAX 的想法是将尽可能多的数据行存储到一个块中，但在块内将它们存储在列中。这保留了列存储的一些压缩和缓存效率优势，同时还可以在一个步骤中恢复整行。 （我认为 Vertica 的 FlexStore 做了类似的事情，但我不确定。）
更令人困惑的是，VectorWise 的 Peter Boncz 告诉我 VectorWise 可以支持列式存储和 PAX 的“任何混合”。
底线：行存储和列存储之间的区别不会很快消失，但至少开始有点模糊。
