sql - Redshift 查询计划器和视图
问题描述
我在一些非亚马逊资源中看到 Redshift 查询规划器在处理视图时遇到问题(这里是一个源,这里是另一个,这里是第三个)。我所说的视图是指标准 SQL 视图,而不是新可用的物化视图。但是,我在开发人员指南中找不到任何关于此的信息,而且上面列出的这些资源已经过时了几年。有谁知道 Redshift 查询计划器和视图的当前情况,如果有描述它的官方 Redshift 文档,它位于哪里?
解决方案
正如您所说,博客的论点有点过时,因为它们作为观点的主要缺点之一是它们在撰写本文时无法具体化,现在情况已不再如此。
第一个链接只是说 Redshift 在优化涉及视图的查询方面遇到了麻烦,但没有显示任何基准/证明,也没有解释原因和方式。
第二个和第三个来源有更多的优点,因为它们实际上提供了替代方案,即创建一个实际的表或物化视图。
我的理解是 Redshift 中的视图本身并不会受到性能不佳的影响,而是考虑到它们的瞬态特性,它们没有利用 Redshift 的集群架构。此外,正如您链接的一些资源所提到的,构成视图的查询在您每次查询视图时都会执行,这绝对无助于性能。我肯定会建议您考虑在实际表中聚合您的数据或考虑具体化这些视图。
为了更好地理解规划器的工作方式,我将看看这个查询规划和执行工作流
推荐阅读
- angular - 带有 Auth0 的 Microsoft Teams 选项卡加载应用程序
- php - 如何将带有子查询的 SQL 查询转换为 Doctrine QueryBuilder 格式?
- java - XPATH:尝试从跨度类包含某些文本的元素中选择按钮
- placeholder - 占位符禁用联系表格 7 中的要求检查
- javascript - 如何将 div 的高度设置为 100vh - 改变高度时的响应式导航栏高度?
- python - Python 检查线程是否还活着
- reactjs - 24 小时后对复选框的更改值做出反应
- kotlin - Kotlin 脚本构建失败
- bazel - Monorepo 与多个连接的 Bazel 工作区 - 是否有任何“陷阱”需要考虑?
- dependency-injection - blazor wasm 如何从 di 注入自定义类