在排序操作中,主要的瓶颈是磁盘I / O,即从磁盘中获取所有数据。
所以我想用Postgres的IMCS和内存中的柱状插件进行实验。
以下是常规查询计划。(我没有包含用于学习目的的索引)
perf_test=# explain (analyze,buffers) select * from users_act_demo order by userid limit 10;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=410011.04..410011.06 rows=10 width=14) (actual time=4328.393..4328.396 rows=10 loops=1)
Buffers: shared hit=3 read=59875
-> Sort (cost=410011.04..437703.22 rows=11076875 width=14) (actual time=4328.387..4328.389 rows=10 loops=1)
Sort Key: userid
Sort Method: top-N heapsort Memory: 25kB
Buffers: shared hit=3 read=59875
-> Seq Scan on users_act_demo (cost=0.00..170643.75 rows=11076875 width=14) (actual time=0.042..1938.043 rows=11076719 loops=1)
Buffers: shared read=59875
Planning time: 42.055 ms
Execution time: 4328.482 ms
(10 rows)
执行cs_load
后,这是一个将所有页面移动到内存中的函数。之后,下面是查询计划。
perf_test=# explain (analyze,buffers) select * from users_act_demo order by userid limit 10;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=410011.04..410011.06 rows=10 width=14) (actual time=3902.765..3902.767 rows=10 loops=1)
Buffers: shared hit=59875
-> Sort (cost=410011.04..437703.22 rows=11076875 width=14) (actual time=3902.763..3902.763 rows=10 loops=1)
Sort Key: userid
Sort Method: top-N heapsort Memory: 25kB
Buffers: shared hit=59875
-> Seq Scan on users_act_demo (cost=0.00..170643.75 rows=11076875 width=14) (actual time=0.028..1520.772 rows=11076719 loops=1)
Buffers: shared hit=59875
Planning time: 0.145 ms
Execution time: 3902.827 ms
我的问题是,为什么排序不快?如果所有数据都不受I / O限制,那么它是不是受CPU限制?为什么它变慢了,这里的成本到底是什么?