学习让我快乐

不见了的千分之一行

最近在基于之前提出的一个 POC 设想 GP 存储计算分离的一种实现为我们 ADB PG OSS 外表加入弹性调度的能力. 当前如果一个查询使用了 OSS 外表, 那么在执行时针对该 OSS 外表的 Foreign Scan 算子总会被调度到所有计算节点上运行, 这里每个计算节点都会分配到, 且只会分配到 1 个 Foreign Scan 算子. 从而来起到一个并行 Foreign Sca...

Posted by w@hidva.com on May 28, 2020

UDP 与 GRO, GSO

不知道是不是因为 GSO, GRO 是 Linux 新增特性的原因, 在 google 上找了半天都没有找到一篇详细的介绍如何使用 GSO/GRO 的文章, 最后从 Linux 内核中与 GSO/GRO 相关的 testcase 中窥到了一丝信息, 总结如下. 另外由于 GSO 是 5.0 新加的特性, 而且手头上也没有 linux 5.0 的机器, 所以如下总结并未实际验证过… GSO,...

Posted by w@hidva.com on May 11, 2020

GP 存储计算分离的一种实现

效果和 presto 中将执行计划切分为多个 Stage 一样, GP 也会将执行计划切分为多个 Slice, 每一个 slice 表示着执行的一个阶段. 在优化阶段, 在 PG 优化器的基础之上, GP 会根据表数据的分布策略在合适的地方加入 Motion 节点, Motion 节点用来根据需要对数据进行重分布. 在优化结束, 执行计划确定了之后, GP 会遍历 plan tree, ...

Posted by w@hidva.com on May 9, 2020

GP udpifc interconnect 两三事

GP interconnect 层, 对上提供了一种可靠有序的数据传输方式, 在查询执行中计算节点之间通过 GP interconnect 层来完成所需的数据交互. 当前 GP 中 interconnect 主要有两种实现: tcp, udpifc. 其中 tcp 便是直接基于 TCP 搭建; udpifc 则是基于 UDP 协议实现, 在 UDP 基础之上加入了 ACK, 重传等机制来实现...

Posted by w@hidva.com on May 4, 2020

QUIC 与 mvfst

前言这篇文章记录了我在学习 QUIC 协议以及阅读 facebook/mvfst 代码时随手记得一些笔记, 并没有多大的条理性以及可读性. 对于第三者读者而言, 老实说并没有多大的价值… 之所以对 QUIC 感兴趣, 是因为想用此替换下 Greenplum 这一 MPP 数据库的 interconnect 层. 当前 Greenplum interconnect 层主要有两种实现: T...

Posted by w@hidva.com on May 2, 2020

PG 中的 builtin function

PG 的 CREATE FUNCTION 支持用户在 create function 时使用 language internal. 此时 AS 子句中跟着的是 PG builtin function 的函数名. 如下所示: CREATE FUNCTION myfloat4abs(float4) RETURNS float4 LANGUAGE internal AS 'float4abs' ...

Posted by w@hidva.com on April 20, 2020

一个普通的遍历实现

最近在看 Greenplum 代码时发现一个比较有意思的代码片段, 这个代码片段解决了一个比较有意思的问题. 抽象着来说, 便是对于一个长度为 N 的数组 A, 数组 A 中每一个元素自身也是一个数组, 记集合 \(\{ M_1, M_2,..., M_N \}\) 为一个组合, 其中 \(M_i\) 为 A[i] 指向数组中成员之一. 现在需要设计一个过程可以完成对所有组合的遍历工作. ...

Posted by w@hidva.com on April 4, 2020

PG 中的优化器: 概念

本文章内容根据 PG9.6 代码而来. 我个人感觉, 对 PG 优化器的学习一定要切合一个特定的链路, 更细化地说是一个特定的查询. 因为 PG 优化器被用来处理所有可能的查询, 它里面包含了大量的分支判断, 虽然 PG 将若干分支进行了一定的抽象汇总, 但是如果没有特定查询场景下, 咋一看也是有点蒙的. 另外该篇文章主要着重于对优化过程中所用到的各种概念的描述, 并未太过详细地描...

Posted by w@hidva.com on March 18, 2020

21亿次事务之后...

最近在看 Greenplum 的分布式事务执行框架, 发现了一个较为有意思的 bug, 该 bug 出现在判定分布式事务先后次序的逻辑上面, 会导致在执行 21 亿事务之后, 准确来说是 2147483659 次事务之后, 后续的分布式事务可能会构造出错误的分布式快照, 导致了之前的事务插入的数据对之后的事务不再可见. 为了能够搞清楚这个 bug 是怎么发生的, 我们先简单介绍下 GP 中的...

Posted by w@hidva.com on March 13, 2020

PG 中的事务: XLOG

本文章内容根据 PG9.6 代码而来. XLOG, 也即 WAL 在 PG 中的别称, 我们这里不对 WAL 背后的细节背景做过多介绍, 更专注与 PG 中是如何实现 WAL 的, 即 PG 的 XLOG 模块. 在 PG 之中, 每一条 XLOG 都对应着一个 XLogRecord, 其内存放着所有与当前 XLOG 相关的信息, 大致来说主要就是: 当前 XLO...

Posted by w@hidva.com on February 8, 2020

指令级优化参考手册: 三

最近在做的一些事对性能要求极其苛刻, 以至于最后不得不下潜到指令级找寻一些可能存在的优化点. 这里总结记录了在此过程中所得到的一些通用化优化规则. 在试图应用这些规则来优化自己的程序之前要首先铭记先贤们说过的: “过早优化是万恶之源”. 因此我们建议除非是使用了 perf 等工具找到了程序热点, 否则不应该首先应用这些规则来对程序进行优化. 我个人认为在写代码的过程中惦记着怎么把这段代码最优...

Posted by w@hidva.com on January 16, 2020

为什么 unlock 时没有唤醒我?

还是我们的 ADB PG 测试实例, 收到了测试脚本执行超时的报警, 看了一下发现是由于已经执行很久的 DELETE 持有的锁阻塞了测试脚本中 DDL 的执行, 又看了一下这个 DELETE backend 的堆栈: #0 0x00002b2049a2af67 in semop () from /lib64/libc.so.6 #1 0x0000000000770bc4 in PGSe...

Posted by w@hidva.com on December 15, 2019

SIGUSR2 导致的血案

有一天忽然收到我们 ADB PG 测试实例重启的报警, 当时上去看了下发现是实例部署个关于内存控制的参数没配置合适导致计算节点 OOM 了, 恰好当时 master 在处于恢复残留两阶段事务的关键链路, 发现无法链接 segment, 毕竟此时 segment 处于 recovery mode, 便 PANIC 退出了. 当时按照预案配置好相关参数, 理论上是需要一次重启才能使实例生效的, ...