Abhisek Goswami：CUDA 与 PostgreSQL：两个世界的双胞胎
内容提要
文章将 PostgreSQL 与 CUDA 比作“双胞胎”：二者起源不同，但都遵循“不让独立工作无谓等待”的理念。PostgreSQL 通过 MVCC 实现读写并发互不阻塞，CUDA 则让 GPU 并行处理海量独立计算。面对上亿行的简单运算，CPU 负责查询、事务与顺序逻辑，GPU 负责重复并行计算。PG-Strom 扩展将二者结合，用 GPU 加速合适负载，但并非万能提速。核心是让正确的工作交给合适的硬件，同时保持数据可信。
延伸解读
MVCC 与 GPU 并行的共同逻辑
文章将 PostgreSQL 的 MVCC 与 CUDA 的并行计算联系起来，指出两者都遵循“不让独立工作无谓等待”的原则。MVCC 通过维护行版本和事务可见性，让读操作不必等待写操作，从而提升并发能力；CUDA 则让 GPU 同时处理大量互不依赖的计算任务。这种类比有助于理解：数据库和 GPU 虽然领域不同，但都在解决“如何让独立任务并行推进”的问题。
GPU 加速的适用边界
文章强调，GPU 并非“让 PostgreSQL 变快”的万能按钮。对于数据量小、高度顺序化、分支复杂或需要频繁搬运小片数据的负载，GPU 可能帮助有限。PG-Strom 这类扩展的价值在于，将适合并行的大批量重复计算交给 GPU，而把查询解析、事务快照、顺序逻辑等仍留给 CPU 和 PostgreSQL。读者应关注负载是否具备“大量独立同构计算”的特征。
PG-Strom 示例的参考意义与局限
文章引用 PG-Strom 公开文档中的示例，说明 GpuPreAgg 可将计算和聚合下推到 GPU，并提到文档记录的约 55 毫秒执行时间。但作者明确表示自己并无 GPU 环境，未实际运行文中简化的 2x+1 查询，因此该数字仅对应文档中的原始负载，不能直接套用到其他查询。这提醒读者：评估 GPU 加速时，应以自身数据量、查询形态和实际测试为准，避免直接照搬基准结果。
算力提升不等于数据可信
文章最后指出，给机器更多 GPU 算力，并不会自动让底层数据更可信。如果数据本身错误、不完整或不一致，更强的并行计算只会更高效地处理错误信息。PostgreSQL 长期积累的事务、一致性、可见性和结构化管理，正是确保数据含义与可信度的关键。因此，GPU 加速的合理方向是让 PostgreSQL 管好数据、CPU 处理控制与顺序逻辑、GPU 承担并行计算，而不是用算力替代数据治理。
Q&A
PostgreSQL 和 CUDA 为什么被比作双胞胎？
因为它们虽然起源不同——PostgreSQL 起源于 1996 年的 POSTGRES 项目，CUDA 由 NVIDIA 于 2006 年推出——但都遵循一个共同理念：不让独立的工作无谓等待。PostgreSQL 通过 MVCC 让读写并发互不阻塞，CUDA 让 GPU 并行处理大量独立计算。
PostgreSQL 的 MVCC 是如何工作的？
MVCC（多版本并发控制）通过维护行版本和事务可见性信息，让不同事务根据各自的快照看到合适的数据版本。这样读操作不必等待写操作完成，写操作也不会阻塞读操作，从而支持高并发。
CPU 和 GPU 在处理计算任务时有什么不同？
CPU 擅长处理复杂指令、分支、顺序工作和少量强大线程；GPU 则拥有大量执行资源，专为同时处理大量相似工作而设计。对于像 f(x)=2x+1 这样对 1 亿个值进行的独立重复计算，GPU 的并行能力更合适。
PG-Strom 是什么？它如何结合 PostgreSQL 和 GPU？
PG-Strom 是一个 PostgreSQL 扩展，利用 NVIDIA GPU 和 CUDA 加速合适的 PostgreSQL 工作负载。它把 GPU 计算引入数据库查询中，例如在 GPU 上执行过滤、计算和聚合（如 GpuPreAgg 计划），但并非所有负载都适合，需要工作量大且可并行。
使用 GPU 加速 PostgreSQL 有什么限制或注意事项？
GPU 不是万能提速按钮。如果工作负载很小、高度顺序化、分支密集，或者需要频繁来回传输小量数据，GPU 可能帮助不大。只有大规模且可独立并行的工作负载才适合交给 GPU。
在 PostgreSQL 与 GPU 协作的系统中，数据可信度为什么仍然重要？
因为给机器更多计算能力并不会自动让底层信息更可信。如果数据错误、不完整或不一致，增加 GPU 核心只会更高效地处理错误信息。PostgreSQL 负责数据含义、事务、一致性和可见性，CUDA 负责大规模并行计算，二者协作才能在不丢失数据正确性和上下文的前提下把正确的工作交给合适的硬件。
