关于PostgreSQL性能改进的几点思路--章晨曦.pdf

《关于PostgreSQL性能改进的几点思路--章晨曦.pdf》由会员分享，可在线阅读，更多相关《关于PostgreSQL性能改进的几点思路--章晨曦.pdf（26页珍藏版）》请在三个皮匠报告上搜索。

1、PostgreSQL中文社区第13届PostgreSQL中国技术大会聚焦云端创新汇聚智慧共享章晨曦（Jet）关于PostgreSQL性能改进的几点思路PostgreSQL中文社区性能瓶颈（一）的应对方案03可能存在的性能瓶颈0102PostgreSQL中文社区目录contents性能瓶颈（二）的应对方案01可能存在的性能瓶颈PostgreSQL中文社区PostgreSQL中文社区01 可能存在的性能瓶颈 SQL硬解析带来的巨大开销PostgreSQL中文社区01 可能存在的性能瓶颈 SQL硬解析带来的巨大开销SELECT abalance FROM pgbench_accounts WHERE

2、 aid=1000;PostgreSQL中文社区01 可能存在的性能瓶颈 SQL硬解析带来的巨大开销SELECT abalance FROM pgbench_accounts WHERE aid=1000;PostgreSQL中文社区01 可能存在的性能瓶颈 SQL硬解析带来的巨大开销SELECT abalance FROM pgbench_accounts WHERE aid=1000;PostgreSQL中文社区01 可能存在的性能瓶颈 SQL硬解析带来的巨大开销 UPDATE导致的数据块膨胀PostgreSQL中文社区01 可能存在的性能瓶颈 UPDATE导致的数据块膨胀CREATE T

3、ABLE ta(a INT,b VARCHAR(10);INSERT INTO ta VALUES(1,aaaaaaaa);DO$BEGIN FOR i IN 1.100000 LOOP UPDATE ta SET b=aaaaaaAB WHERE a=1;END LOOP;END;$LANGUAGE plpgsql;膨胀了545倍！02性能瓶颈（一）的应对方案PostgreSQL中文社区PostgreSQL中文社区02 性能瓶颈（一）的应对方案PREPARE为什么更快？PREPARE阶段EXECUTE阶段PostgreSQL中文社区02 性能瓶颈（一）的应对方案引入SQL软解析的能力SELE

4、CT abalance FROM pgbench_accounts WHERE aid=1000;SELECT abalance FROM pgbench_accounts WHERE aid=$1;$1:=1000PostgreSQL中文社区02 性能瓶颈（一）的应对方案引入SQL软解析的能力后的性能表现pgbench-r-j16-c16-T60-P5-S-p 5492 bench1020000400006000080000100000120000140000160000180000QPSQPSstatement_sharing=normalstatement_sharing=nonePos

5、tgreSQL中文社区02 性能瓶颈（一）的应对方案SQL软解析优势 实际环境更优的性能表现 对应用透明SQL软解析劣势处理逻辑变得更复杂需要额外的内存空间03性能瓶颈（二）的应对方案PostgreSQL中文社区PostgreSQL中文社区03 性能瓶颈（二）的应对方案INSERT的过程PostgreSQL中文社区03 性能瓶颈（二）的应对方案DELETE的过程PostgreSQL中文社区03 性能瓶颈（二）的应对方案UPDATE的过程PostgreSQL中文社区03 性能瓶颈（二）的应对方案TUU（Tuple-level Update-only Undo）技术方案PostgreSQL中文社区

6、03 性能瓶颈（二）的应对方案TUU（Tuple-level Update-only Undo）技术方案Undo-Tuple Chain(Per-Tuple)PostgreSQL中文社区03 性能瓶颈（二）的应对方案TUU（Tuple-level Update-only Undo）技术方案Undo-Tuple Pages(Per-Relation)PostgreSQL中文社区03 性能瓶颈（二）的应对方案TUU方案的性能表现CREATE TABLE ta_ipu(a INT,