我有以下输出

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)。但是,请注意,“读取”数据可能来自文件系统缓存。

10-06 01:30