我有以下输出
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
行中提到的行。但是为什么最上面的
464065 - 456425 = 7640
显示实际的行数为Seq Scan
?它是从哪里来的?我想这可能与第二个排序操作有关,但那是完全不同的分支。
有没有办法知道表是否适合内存?平面图表示正在使用的内存量,但我看不到它们表示是否所有这些都适合内存。
最佳答案
我不确定,但我猜“Merge Join”只消耗了“Sort”节点的5634行。
PostgreSQL的执行是按需执行的,也就是说,只要上一个节点需要,就从下一个节点请求一个结果行。
虽然“Sort”肯定需要“Seq Scan”中的所有行,但合并连接可以在读取所有可用的排序行之前完成。
这不是您的问题,但要加快查询速度,您需要在people (name)
和movies (title)
上建立索引。
要知道数据是否已缓存,请使用EXPLAIN (ANALYZE, BUFFERS)
。然后可以看到在缓存中找到的块数(hit)和从操作系统读取的块数(read)。但是,请注意,“读取”数据可能来自文件系统缓存。