向量化引擎
PolarDB PostgreSQL版支持向量化引擎，可以让您更好地适应复杂查询的需求。
简介
原生PostgreSQL执行引擎基于火山模型，底层存储基于Heap的行存结构，统称为行存引擎。在行存引擎中，每个算子（如Scan、Sum等）每次只能处理一条数据，当数据量较大时，将导致IO和函数调用耗时过长，不适合统计与分析类的查询。
PolarDB PostgreSQL版向量化引擎也称列存引擎，相对于行存引擎，主要在两个层面进行优化：存储层面的列存索引和执行引擎层面的向量化算子，从而弥补行存引擎在复杂查询场景的不足。以TPC-H 100GB为例，在32核256 GB集群规格中，PolarDB PostgreSQL版向量化引擎比行存引擎性能提升50倍以上，详细介绍请参考性能指标。
向量化引擎作为行存引擎的补充，二者的协同存在使得PolarDB PostgreSQL版不仅保留高性能事务处理的能力，也可以大幅提升复杂查询的性能。其使用场景包括：
HTAP场景。例如每天需要对大量的交易数据进行增删改查，同时也需要实时统计出过去一小时的交易报表。PolarDB PostgreSQL版向量化引擎不仅能够高效应对这两类负载，还可以简化系统架构，无需为实时统计部分OLAP查询维护额外的系统。
各类慢SQL。在高并发事务场景中出现的慢SQL，如：
全表统计，如
Count、Sum、Average等操作。对列进行
Group By和Order By等操作。对多个表做
Join操作。查询时过滤的列较多且顺序不定，复合索引不灵活且容易失效，使用列存索引更优。
多模类型与时空查询。例如在嵌套JSON中提取
Key和Value、基于地理网格统计时空热力图等。
技术原理
向量化引擎与列存
PolarDB PostgreSQL版向量化引擎在执行引擎和存储层面进行了优化，以更好地适应复杂查询的需求。
执行引擎层面
不同于行存引擎，向量化引擎利用CPU的SIMD指令来批量化处理数据，即一条CPU指令可并行处理多条数据，从而减少函数调用耗时以及Cache Miss问题。
实现完整的向量化算子。如
Scan、Group By、Order By、Hash Join、Filter、Count、Sum等算子的向量化，使其能够接收批量化的数据输入并利用SIMD指令进行处理。
存储层面
采用更适合向量化算子的列存格式，而非Heap行存结构。
列存格式目前以索引的形式存在，即列存索引。列存索引与B-tree索引、GiST索引具有相似性，仅在存储结构和适用场景上存在差异。列存索引将被向量化引擎使用，而B-tree、GiST等索引则被行存引擎使用。一个表中可以同时存在列存索引和其他类型的索引来应对不同的查询，PolarDB PostgreSQL版优化器会根据查询计划的代价来选择不同的索引。
如下图所示，您可以为表t的c2列创建B-tree索引来应对点查（SELECT * FROM t WHERE c2=10），为c4和c5列创建列存索引来应对统计类查询（SELECT c4, SUM(c5) FROM t GROUP BY c4），查询优化器会根据查询SQL的查询代价选择合适的索引。
行列数据实时同步
向量化引擎使用的列存数据以列存索引形式存在。数据会先写入到行存表中，然后通过索引机制更新至列存索引，此过程被称为行列数据的同步。PolarDB PostgreSQL版向量化引擎提供高效、实时且自动化的行列数据同步机制，在使用时无需为此过程搭建额外链路，也无需手动刷新列存数据。
向量化引擎行列数据同步机制的基本原理是通过解析WAL日志来获得变化的数据，进而将其异步写入到列存索引。该过程对行存数据的负载和性能几乎没有影响，对行存性能的影响保持在3%以下。由于PolarDB PostgreSQL版向量化引擎与行存引擎可以部署在同一个节点中，因此在解析WAL的过程中进行了大量优化。尽管行列转换的过程为异步，但依旧可以实现毫秒级至秒级的实时同步（取决于写入负载）。行列数据实时同步性能调优请参考列存索引的实时性。
产品形态
PolarDB PostgreSQL版向量化引擎将在所有节点上部署，因此集群中的所有计算节点均同时具备行存引擎和向量化引擎。在这种模式下，一条SQL语句在执行时会面临两个选择：
该语句将被分配到哪个节点执行，即选择计算节点。
该语句由节点内的哪个引擎执行，即选择执行引擎。
选择计算节点
当PolarDB集群存在多个节点，与列存索引相关的SQL语句将面临由哪个计算节点执行的问题。
所有涉及数据更改的语句均由RW节点执行，如DDL和DML语句。在RW节点内部将进一步根据具体条件选择执行引擎。
创建列存索引、列存索引实时同步都在RW节点执行。
所有只读SQL语句，可通过设置数据库代理来决定使用哪个节点来执行，详细介绍请参考数据库代理。
选择执行引擎
在计算节点内部，执行语句需要选择使用的执行引擎。
对于DDL类型语句，如
CREATE TABLE、ALTER TABLE等，一般使用行存引擎。但CREATE TABLE AS SELECT语句会根据SELECT子语句的复杂度来选择是否使用向量化引擎。对于DML类型语句，如
INSERT、UPDATE、DELETE等，使用行存引擎。对于DQL类型语句，如SELECT语句，将根据查询代价和参数来决定是否使用向量化引擎。一般来说SELECT语句的查询代价越大，使用向量化引擎的概率越大，详情请参考使用向量化引擎功能。如果向量化引擎执行SELECT语句失败，将会使用行存引擎重新执行。
功能优势
高性能
相比于行存引擎，向量化引擎能够将SQL查询性能普遍提升一个数量级，针对复杂查询提供百倍以上的性能提升。
低成本
只需为查询涉及列创建列存索引，无需将整个表转换为列存。
列存索引的存储空间占用较小。对于同一列，列存索引的空间占用仅为行存的10%~50%（具体取决于数据类型）。
使用方式简单
使用流程与原生PostgreSQL一致。
实时列存索引数据
自动维护行存数据与列存索引之间的一致性，无需额外构建行列数据转换链路，无需手动刷新同步列存索引等操作。
行存中新插入的数据可在毫秒/秒级同步到列存索引中，可根据不同的业务负载调整同步性能，详情请参考开启和使用向量化引擎。
一致性
为列存数据和行存数据提供两种一致性级别，以满足不同业务需求。
最终一致性（默认）：适用于写入负载高，但对数据实时性要求低的查询。
强一致性：在列存数据与行存数据完全一致后再返回查询结果，详情请参考查询一致性。
兼容多种使用方式
支持
Prepared Statement语法。支持事务块中的SELECT语句加速。
说明该SELECT语句必须为事务块内的“写前读”SQL。
支持分区表和pg_pathman管理的分区表，并支持分区裁剪能力，详情请参考分区表使用列存索引。
支持时空多模态查询加速。
费用说明
PolarDB PostgreSQL版向量化引擎不单独收费。