问题标签 [lateral-join]

这是我正在尝试的查询，

在实现这一点时，我的朋友建议，我们可以使用 LEFT JOIN LATERAL 并只计算一次，而不是每次在 switch case 中计算 array_agg。即）执行如下

但我不确定 Postgres 是否ARRAY_AGG每次都计算该值，我们如何确定哪种方法更好？我尝试查看explain analyse这两个查询，后者查询中涉及的行数比前者多。但我不明白为什么会这样？

我凭直觉觉得前一种方法更好，但是有人可以解释一下，哪种更好，为什么还是我要求太多？

我有下表

vehicles - id, name

vehicle_settings - id, settings, vehicle_id, company_id, updated_at, updated_by

vehicle_licenses - id, license_number, vehicle_id, company_id, updated_at, updated_by

users - id, name, email

一辆车可以有多个条目，vehicle_settings并且可以有多个条目vehicle_licenses 该车辆可能没有vehicle_settings或车辆许可证。

现在，我需要最后更新车辆设置或许可证的用户的所有车辆列表。我还应该能够过滤带有车辆 ID 的列表，并能够计算所有符合过滤条件的车辆的数量。

所以，我尝试了以下查询

此查询运行良好，但是计数具有误导性。我得到的计数比车辆的数量多。也许它也需要LEFT LATERAL JOIN我猜的条目。

如果我尝试在同一个查询中加入和横向展平，我会遇到语法错误。我创建了以下示例：

设置

并设置一个表加入：

例子

基本横向展平工作：

问题

“SQL 编译错误：位置 59 处的错误行 9 无效标识符 'MAIN_TABLE.DEPARTMENT_ID'”

更有效

-- 没有横向展平的基本连接

这是来自 aws 网站的片段：

它有效！但是什么t(sites)意思？当我尝试使用真实表而不是dataset出现错误时Table 'site' not found。

它看起来很奇怪 - 类似于使用UNNEST关键字调用的函数。有人可以解释这是什么吗？

我有一个lateral join这样定义：

具有limit 1内部的特殊点（在更复杂的情况下，我可以在连接中有一些额外的选项来缩小值和/或order by）。我知道在 Spark-SQL 中目前没有类似的东西，那么我怎样才能找到解决方法呢？

I have the following query

So instance_versions subquery is executed with every value of timestamps generated from time_series query(see the last select statement). But for some reason the lateral join is very slow,the rows returned by the subquery of lateral join ranges in around 12k-15k(for a single timestamp from time_series query) which is not a big number and the final no of rows returned after the Lateral join ranges from 250k-350k. Is there a way i can optimize this?

我有以下数据结构，表名以粗体显示，下面的相关列名。

common_authorprofile:

aldryn_people_person 表：

aldryn_newsblog_article：

值得注意的是，common_authorprofile.profile_id = aldryn_people_person.id和aldryn_newsblog_article.author_id = aldryn_people_person.id

我正在尝试计算common_authorprofile.

这是目前的做法：

我的问题有两个：

• 鉴于表关系，这是一种正确的做法吗？
• 这是一种有效的方法吗，即有没有办法提高它的速度和可读性？

我为一个客户创建了一个查询，我一直在调整它，试图让它正好满足他们的需求。除了一些奇怪的计数外，我几乎把它设置好了。经过一个严肃的 FACEPALM 时刻后，我意识到 COUNT 和 SUM 中的 DISTINCT 正在抛弃我的数字，所以我删除了它们。

但是，现在查询似乎永远运行，而过去需要 2-3 分钟。我让它在一夜之间运行，它在 5 小时后崩溃并出现以下错误：

由于文件组“DEFAULT”中的磁盘空间不足，无法为数据库“TEMPDB”分配新页面。通过删除文件组中的对象、向文件组中添加其他文件或为文件组中的现有文件设置自动增长来创建必要的空间。

tempdb.mdf 为 16Gig，我有 7 个 tempdb_mssql_#.ndf 文件，每个文件为 16Gig，我的日志文件为 4Gig，非常高兴地完全填满了我的硬盘。

我重新启动了服务器并缩小了数据库，所以我又回到了原点，但我不明白为什么会这样。

这是导致问题的查询：

• AllPartsList 有 130 万条记录
• E_Part 有 20,500 条记录
• bomBreakdown 有 130 万条记录

以前，在外部应用中，除前两个之外的所有查询都有 DISTINCT，但我删除了它们。使用 DISTINCT 查询运行良好，数字刚刚关闭。

我不认为这是数据/表格布局问题，我认为可能存在交叉连接或我遗漏的东西。

我有下表：

是否有可能通过子查询/横向连接获得以下输出：

因此，如果水果为空，则获取父母的水果。尝试使用子查询来获取此信息，收集链接的父母以从中获取水果值，但在这种情况下，这些值与他们的 ID 配对，而不是与“孩子”ID 配对。所以是这样的：

当我的数据库中有一个没有帖子的类别时，结果选择返回没有空类别的行。如何接收具有空类别的表格。

当前查询结果：

我需要：