当前位置:首页 > 报告详情

PostgreSQL全表count-权宗亮.pdf

上传人: 茫然 编号:731586 2025-07-14 15页 265.59KB

1、PostgreSQL PostgreSQL 全表全表 countcountIvorySQL 2025IvorySQL 2025生态大会生态大会暨暨PostgreSQLPostgreSQL高峰论坛高峰论坛SeqScan SeqScan 现状现状heapam heapam 改进改进全表计数目录CONTENTSIvorySQL 2025IvorySQL 2025生态大会生态大会暨暨PostgreSQLPostgreSQL高峰论坛高峰论坛SeqScan SeqScan 现状现状IvorySQL 2025IvorySQL 2025生态大会生态大会暨暨PostgreSQLPostgreSQL高峰论坛高峰论

2、坛1 千万记录,2.63 GB,34.5 万块postgres=#SELECT pg_relation_size(c1);pg_relation_size-2824830976(1 row)postgres=#SELECT pg_relation_size(c1)/8192;?column?-344828(1 row)IvorySQL 2025IvorySQL 2025生态大会生态大会暨暨PostgreSQLPostgreSQL高峰论坛高峰论坛postgres=#EXPLAIN ANALYZE SELECT*FROM c1;QUERY PLAN -Seq Scan on c1 (cost=0.

3、00.444828.00 rows=10000000 width=223)(actual time=0.027.2373.527 rows=10000000.00 loops=1)Planning:Buffers:shared hit=59 read=10 Planning Time:1.539 ms Execution Time:3249.865 mspostgres=#EXPLAIN ANALYZE SELECT count(*)FROM c1;QUERY PLAN -Aggregate (cost=469828.00.469828.01 rows=1 width=8)(actual ti

4、me=3974.700.3974.702 rows=1.00 loops=1)-Seq Scan on c1 (cost=0.00.444828.00 rows=10000000 width=0)(actual time=0.038.2315.244 rows=10000000.00 loops=1)Planning Time:0.157 ms Execution Time:3974.804 msIvorySQL 2025IvorySQL 2025生态大会生态大会暨暨PostgreSQLPostgreSQL高峰论坛高峰论坛火山模型每次都是计算一个 tuple(Tuple-at-a-time),

5、这样会造成多次调用 next,也就是造成大量的虚函数调用,这样会造成 CPU 的利用率不高。某商业产品顺序扫描快 2 倍以上IvorySQL 2025IvorySQL 2025生态大会生态大会暨暨PostgreSQLPostgreSQL高峰论坛高峰论坛heapam heapam 改进改进IvorySQL 2025IvorySQL 2025生态大会生态大会暨暨PostgreSQLPostgreSQL高峰论坛高峰论坛IvorySQL 2025IvorySQL 2025生态大会生态大会暨暨PostgreSQLPostgreSQL高峰论坛高峰论坛all_visible=PageIsAllVisible

6、(page)&!snapshot-takenDuringRecovery;for(lineoff=FirstOffsetNumber;lineoff rs_base.rs_rd,&loctup,buffer,snapshot);if(valid)scan-rs_vistuplesntup+=lineoff;IvorySQL 2025IvorySQL 2025生态大会生态大会暨暨PostgreSQLPostgreSQL高峰论坛高峰论坛CheckForSerializableConflictOut()略 if(!SerializationNeededForRead(relation,snapsho

word格式文档无特别注明外均可编辑修改,预览文件经过压缩,下载原文更清晰!
三个皮匠报告文库所有资源均是客户上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作商用。
本文主要讨论了IvorySQL 2025生态大会暨PostgreSQL高峰论坛上关于PostgreSQL全表计数性能的改进。以下是关键点: 1. 全表计数操作:在千万记录、2.63GB大小的表上,使用`SELECT count(*) FROM c1`进行全表计数,执行时间为3249.865ms。 2. 性能瓶颈:火山模型处理方式导致多次虚函数调用,降低CPU利用率,某商业产品顺序扫描性能快2倍以上。 3. heapam改进:通过减少分支判断,优化`heapgetpage()`中的每元组循环。 4. 全表计数优化:利用Visibility Map和Page Header信息,优化后全表计数操作执行时间缩短至661.419ms。 引用核心数据:`pg_relation_size('c1')`返回结果为2.82亿,即表大小;优化前后全表计数执行时间分别为3249.865ms和661.419ms。
"PostgreSQL全表计数有多快?" "如何提升PostgreSQL SeqScan性能?" "IvorySQL 2025大会带来了哪些改进?"
客服
商务合作
小程序
服务号
折叠