意义，忘记这个事情就好了， 好好使用ZSTD就对了。 在列上设置压缩 注意：编者不希望读者浪费很多时间来学习这部分的知识，所以，先把观点列出来，编 者根据10年的经验判断，除了作为一块知识来学习外，可能永远也不需要在每个字段 上设置压缩，因为那是极其多余和毫无意义的。在真实的使用环境中，往往列存储的选 择都应该是极其少见的，因为列存储的选择需要满足多方面条件，选择列存的往往是那 很重要，后面还会提到。 对于这个执行计划应该只显示对下列表的扫描：  默认分区返回0-1条数据(可能不止一个默认分区，PostgreSQL优化器一定会扫 描默认分区，Orca根据条件判断，不一定会扫描默认分区)  符合日期的USA地区叶子分区(sales_1_2_prt_usa)返回一些记录 从PostgreSQL优化器生成的执行计划发现，有3个默认分区被扫描了，分别是第 ap表的同一个分布键上。  由Orca优化器生成的在一张Hash分布的Heap表上同一条记录的并发UPDATE。 注意：GP 数据库使用 deadlock_timeout 参数来判断本地死锁，由于本地死锁与全 局死锁的检测算法不同，可能会被本地死锁检测发现，也可能被全局死锁检测发现，这 取决于哪个先发现。 Greenplum Database 管理员指南 V6.2.1

No-force ● redo log，没有undo log，事务回滚不需要做undo操作 • PG采用的是MVCC，更新操作不是in-place update，而是重新创建tuple， 可见性判断 • Robert Haas 2018, “DO or UNDO - there is no VACUUM”: zheap, in-place update PostgreSQL和Greenplum采用的策略 QD向QE发起两阶段提交 • 分布式快照 • QD向QE发送全局快照信息 • Writer QE和Reader QE共享本地快照信息 • distributed log：分布式事务提交日志 • 用于判断分布式事务是否提交，作用和PG 的commit log类似，基于simple LRU实现 • 分布式死锁检测 • 本地事务的管理：创建、提交、状态迁移 等 • 加锁和MVCC • 本地事务的死锁检测

v1使用omreport工具来检查，DCAv2采用CmdTool2 或MegaCli 问题定位方法 现象-系统突然运行缓慢 对于此类问题，问题原因可能是多方面的，定位比较困难，首先需要判断是硬件原因导致还是应用本身的原因导致，是某一SQL导致还是整体运 行变慢，找到具体的原因后，才能确定应对措施  检查當前所有设备IO,CPU使用情況： – CPU是否繁忙(gpssh –f queries_history wheretfinish >=#datetime# and tstart<=#datetime#; 查询某一时间正在运行的SQL非常有用，可以帮助我们重现当时的情景，有助于判断那个SQL是否有问题，找到问题根源  Linux工具可以帮助我们跟踪进程状态和监控系统资源使用情況，有助于分析定位问题 – strace – pstack – gdb（在support指导下使用）

断的创新能力和资源，让产品保持持续旺盛的生命力。 这也是我们在用户选型时，通常建议用户考察一下底层的技术支撑 是不是有好的组织和社区支持的原因，如果缺乏这方面的有力支持 或独自闭门造轮，那就有理由为那个车的前途感到担忧，一个简单 判断的标准就是看看底下那个轮子有多少人使用，有多少人为它贡 献力量。 2) 为什么是 Postgresql 而不是其它的？ 我想大家可能主要想问为什么是 Postgresql