| 4 关于本白皮书 近日，Greenplum 社区和欧拉开源社区深化合作，在欧拉开源操作系统（openEuler, 简称“欧拉”）编译测试了高级分 析数据平台 Greenplum，用实践证明了 Greenplum 与支持多样性计算的欧拉开源操作系统完全兼容，是 Greenplum 与中国本地 IT 厂商的深入合作的典型模板，大大丰富了中国本地国产化应用生态。本白皮书着眼介绍了欧拉开源操作系

-- 大量的分析查询但却极少的数据修改。不适 合大量并发事务更新数据的OLTP类型应用。 和B-tree相比，Bitmap索引的使用应该更保守。建议在建立Bitmap索引之后做 必要的测试以证明其可以对查询性能有改善(相对于做全表扫描查询)。另外，最好跟 其他索引类型做必要的对比，就编者的经验来看，正如前面[何时使用位图索引]章节 的[注意]部分所述，可能在很多需要使用索引的时候，直接选择B-tree就足够了，使 以前有不少人以写得出一个巨大无比的单条SQL搞定一个复杂的问题而自我陶醉， 带来的后续维护问题是痛苦的，反而拆分为多个相对简单的步骤更便于排查问题和 维护。编者认为，优雅而高效的解决问题才最重要，故意把问题复杂化不值得提倡， 那不能证明能力。  定义一个大而全的视图，涉及很多表，然后可以用于各种场景 -- 这种设计也是 极其糟糕的，乍一看很酷，实际上，因为适用的场景多，就很难兼顾到每个场景， 所以，可能有的场景SQL 下的XFS挂载参数： rw,nodev,noatime,inode64 早些年的版本中，会提到一个挂载参数： allocsize=16M 注意：这个挂载参数已经被证明，是一个不应该使用的挂载参数，这个参数除了会带来 麻烦，并不会带来任何的好处，因为针对所有的空间请求，XFS第一次都分配16MB是 极其浪费的，在一些极端场景，甚至会导致磁盘空间突增直至空间不足。