我一直在仔细阅读以下两个链接：
postgres是否会使用窗口函数（aggregate）将where子句下推到视图中？
https://dba.stackexchange.com/questions/151169/are-views-harmful-for-performance-in-postgresql
在上面的链接中有一些评论建议了我对两个相关问题的答案，但我想确保我能理解。
假设我有一个观点：
create view A as
select
x.xKey,
x.y,
x.z,
y.yKey,
y.a,
y.b
from x
join y
on x.xKey = y.xKey现在我有另一个。。。
create view B as
select
A.xKey,
A.y,
A.z,
A.yKey,
A.a,
A.b,
r.rKey,
r.n
from A
join r
on A.yKey = r.yKey假设第三个视图c做了更多相同的事情，但是所有三个视图都是纯select语句。
两个问题：
如果我使用与所涉及的任何/所有表相关的过滤器从视图c中选择，那么“ predicate ”是否总是“下推”（对我来说是一个新短语，希望我正确地说了这一点），这样视图c就和以同样方式构建的更大的独立查询一样高效地过滤了？
如果我从视图c中选择，但我没有使用所有联接中涉及的所有表，那么我确实付出了代价，这可以通过手工创建的select语句避免，该语句联接了较少的表。对？
提前谢谢你的想法。
1条答案
按热度按时间sgtfey8w1#
欢迎Maven指正。
我不擅长阅读explain语句，但是我可以很好地剪切和粘贴sql，而且我可以很好地阅读秒表。
我要说的是。
嵌入式视图，即使是简单的视图，也会给执行速度带来一些严重的问题。
我只是回答了我自己的问题，用了一个视图g，它是（或曾经是）类似的东西（使用我的a，b，c类比，在op中提出），从视图f中选择使用e。。。降到a。
为单个筛选行选择结果花费的时间太长，大约为500毫秒。
通过减少沿途捕获的额外表格，我将其减少到200毫秒。我在那里得到了一些东西，一点也不震惊。有点震惊，看看有多少。
但是后来我把200ms降到了7ms，用视图g替换了视图b，而用b的结构作为视图g的一部分。它使视图g的阅读变得更加复杂，但效率却惊人地提高。
把普通连接抽象出来就这么简单了。
所以这回答了我的第一个问题与响亮的不！在postgresql中，使用嵌套视图的视图比完全不使用嵌套的逻辑等价视图的效率要低得多。
我的建议：如果性能受到影响，不要认为嵌套视图是无辜的。他们很可能会伤害你。
糟透了。
我开始理解如何阅读解释结果。关键是嵌套视图是用这个解释的。。。
而我的视图避免了嵌套视图的使用，实现了这一点。。。
当我将两个视图连接在一起时，postresql没有使用理想的索引。