本系列文章主要目的是记录个人的源码学习过程并总结成文档方便后续翻看，同时也记录OG社区（也可能涉及部分postgres）存在问题的发现场景、定位过程和问题根因做一些分析和讨论。下定决心写这篇文章主要是受到了很多前辈的影响，有的人熟悉Oracle/mysql，有的人熟悉pg/greenplum，很多前辈都总结分享了大量资料，包括数据库内核解析的书、课程，以及各种方式的博客分享。这些材料在我学习数据库

上一篇举例子说明了在计划生成过程中，算子可能出现行数偏差较大的情况。那么这篇就从代码的角度分析一下OG是怎么估算表的行数，以及为什么有时候出现这么大的偏差。

执行计划可以说是排查SQL执行慢的必备手段，迁移或者业务中遇到烂SQL或者慢SQL，执行计划可以更好地帮助排查问题根因。很多数据库基础算子的主要逻辑都是类似的，比如全表扫描、索引扫描、Nestloop Join、HashJoin、Group、Order等等，我们还是以openGauss为例，对于主要的算子做一些说明。优化器大多选择估算模型，有的时候会出现这种很明显的bad case。本篇文章主要介

博客中介绍了代价估算和路径选择的一些基本概念和SeqScan的代价模型，大家也都知道一般条件选择率比较低的情况下更容易命中索引，反之更倾向于全表扫描。本篇博客就从优化器源码来分析一下表上存在索引的情况下是如何选择更优的扫描路径，以及索引扫描算子的代价模型是怎样的。索引扫描的逻辑相比于顺序扫描要复杂很多，优化器部分选择路径和计算代价也更为精细，篇幅原因本博客只对主要流程做了说明。

上篇文章介绍了一个简单查询里如何为基表生成SeqScan计划，这篇文章从执行器和存储引擎的角度介绍一下SeqScan算子是如何执行的。执行器框架有很多博主都做了全面并且详细的分析，可以参考博文PostgreSQL内核学习（十五）—— （ExecutorRun）本篇博客简单介绍了OpenGauss执行器和astore存储引擎的SeqScan逻辑，可以清晰看到火山模型运行过程中是如何处理一行记录的。

关于优化器、执行器的主要逻辑有很多文章和书籍进行说明，比如查询解析、查询重写、路径生成、计划生成和执行器及算子。所以系列博客还是准备对源码做较多的分析，计划后面的文章从一个算子的优化器到执行器进行详细的代码走读与分析。那么这篇文章先对SeqScan的优化器部分进行分析，从行数估算、代价估算以及路径/计划生成做一个整体的介绍。下篇文章对执行器和存储引擎进行介绍，全面地了解一个表内的数据是如何读取并返

本系列文章主要目的是记录个人的源码学习过程并总结成文档方便后续翻看，同时也记录OG社区（也可能涉及部分postgres）存在问题的发现场景、定位过程和问题根因做一些分析和讨论。下定决心写这篇文章主要是受到了很多前辈的影响，有的人熟悉Oracle/mysql，有的人熟悉pg/greenplum，很多前辈都总结分享了大量资料，包括数据库内核解析的书、课程，以及各种方式的博客分享。这些材料在我学习数据库