了解 EXPLAIN ANALYZE 查询计划
Understanding EXPLAIN ANALYZE query plan
我有以下输出
Merge Join (cost=31843.55..32194.92 rows=30215 width=36)
(actual time=496.720..510.071 rows=38381 loops=1)
Merge Cond: (movies.year = people.birth_year)
-> Sort (cost=9905.45..9918.62 rows=5268 width=22)
(actual time=151.781..152.690 rows=5634 loops=1) // <---- !!!! LOOKING HERE !!!!
Sort Key: movies.year
Sort Method: quicksort Memory: 729kB
-> Seq Scan on movies (cost=0.00..9579.81 rows=5268 width=22)
(actual time=145.826..149.340 rows=7640 loops=1) // <---- !!!! LOOKING HERE !!!!
Filter: (title > ’y’::text)
Rows Removed by Filter: 456425 // <---- !!!! LOOKING HERE !!!!
-> Sort (cost=21936.87..21953.89 rows=6808 width=18)
(actual time=344.918..347.980 rows=38465 loops=1)
Sort Key: people.birth_year
Sort Method: quicksort Memory: 423kB
-> Seq Scan on people (cost=0.00..21503.44 rows=6808 width=18)
(actual time=341.883..343.847 rows=4151 loops=1)
Filter: (name > ’zeke’::text)
Rows Removed by Filter: 1099324
Planning time: 0.450 ms
Execution time: 511.988 ms
我想知道 title > 'y'
的选择性估计。
这个计划说 Rows Removed by Filter: 456425
.
我们的总行数是 464065
。
由于过滤器删除了 456425
行,我们选择
在 Seq Scan
行中提到的 464065 - 456425 = 7640
行。
但是为什么最上面的 Sort
显示实际行数为 5634
?它来自哪里?
我以为可能和第二次排序操作有关,但那是完全不同的分支。
有什么方法可以知道表是否适合内存?计划指示正在使用多少内存,但我没有看到它们指示所有这些是否适合内存。
我不确定,但我的猜测是“Merge Join”仅消耗了“Sort”节点的 5634 行。
PostgreSQL 执行“按需”工作,也就是说,只要上层节点需要,就从下层节点请求结果行。
虽然“排序”肯定需要“序列扫描”中的所有行,但合并连接可能会在读取所有可用的已排序行之前完成。
这不是你的问题,但为了加快查询速度,你需要在 people (name)
和 movies (title)
上建立索引。
要知道您的数据是否被缓存,请使用 EXPLAIN (ANALYZE, BUFFERS)
。然后您会看到在缓存中找到的块数(命中)和从操作系统读取的块数(读取)。但是请注意,"read" 数据可能来自文件系统缓存。
我有以下输出
Merge Join (cost=31843.55..32194.92 rows=30215 width=36)
(actual time=496.720..510.071 rows=38381 loops=1)
Merge Cond: (movies.year = people.birth_year)
-> Sort (cost=9905.45..9918.62 rows=5268 width=22)
(actual time=151.781..152.690 rows=5634 loops=1) // <---- !!!! LOOKING HERE !!!!
Sort Key: movies.year
Sort Method: quicksort Memory: 729kB
-> Seq Scan on movies (cost=0.00..9579.81 rows=5268 width=22)
(actual time=145.826..149.340 rows=7640 loops=1) // <---- !!!! LOOKING HERE !!!!
Filter: (title > ’y’::text)
Rows Removed by Filter: 456425 // <---- !!!! LOOKING HERE !!!!
-> Sort (cost=21936.87..21953.89 rows=6808 width=18)
(actual time=344.918..347.980 rows=38465 loops=1)
Sort Key: people.birth_year
Sort Method: quicksort Memory: 423kB
-> Seq Scan on people (cost=0.00..21503.44 rows=6808 width=18)
(actual time=341.883..343.847 rows=4151 loops=1)
Filter: (name > ’zeke’::text)
Rows Removed by Filter: 1099324
Planning time: 0.450 ms
Execution time: 511.988 ms
我想知道 title > 'y'
的选择性估计。
这个计划说 Rows Removed by Filter: 456425
.
我们的总行数是 464065
。
由于过滤器删除了 456425
行,我们选择
在 Seq Scan
行中提到的 464065 - 456425 = 7640
行。
但是为什么最上面的 Sort
显示实际行数为 5634
?它来自哪里?
我以为可能和第二次排序操作有关,但那是完全不同的分支。
有什么方法可以知道表是否适合内存?计划指示正在使用多少内存,但我没有看到它们指示所有这些是否适合内存。
我不确定,但我的猜测是“Merge Join”仅消耗了“Sort”节点的 5634 行。
PostgreSQL 执行“按需”工作,也就是说,只要上层节点需要,就从下层节点请求结果行。
虽然“排序”肯定需要“序列扫描”中的所有行,但合并连接可能会在读取所有可用的已排序行之前完成。
这不是你的问题,但为了加快查询速度,你需要在 people (name)
和 movies (title)
上建立索引。
要知道您的数据是否被缓存,请使用 EXPLAIN (ANALYZE, BUFFERS)
。然后您会看到在缓存中找到的块数(命中)和从操作系统读取的块数(读取)。但是请注意,"read" 数据可能来自文件系统缓存。