学习让我快乐

争于世, 不争于势;简洁, 高效, 赏心悦目

一次'失败'的尝试

前言 这个工作的起因是因为某一天在回家的路上我忽然想到了 java 中的 BufferedInputStream. BufferedInputStream 通过为底层各种 InputStream 引入了缓冲区的能力使得读取底层 InputStream 的效率大幅度提升. 那么这个能不能类比到 PG 中呢, 也即能不能引入一个 buffered plan node, buffered pla...

让查询执行动画起来

先看下整个效果 此时对应的查询计划如下: 很显然, 限于黑框框的表现能力, 动画的效果还是很简陋的. 这里最适合的是与配套的前端页面集成起来才够炫酷. 就像 GPCC 那样. 实际上在我第一眼看到 GPCC 中查询执行的动画效果之后, 就一直非常好奇这一效果究竟是如何实现的. 奈何 GPCC 并不开源, 再加上当时技术储备尚且不够, 一直没能如愿, 直到今天. 实际上在对 GP ...

不见了的千分之一行

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

UDP 与 GRO, GSO

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

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

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

GP udpifc interconnect 两三事

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

QUIC 与 mvfst

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

PG 中的 builtin function

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

一个普通的遍历实现

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

PG 中的优化器: 概念

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

21亿次事务之后...

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

PG 中的事务: XLOG

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

指令级优化参考手册: 三

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