问题标签 [query-planner]

n_distinct在 PostgreSQL 中有多种设置方法吗？这两个似乎都在做同样的事情，但最终在pg_attribute. 这两个命令有什么区别？

我想知道 SQL 服务器（或其他 RDBMS）在创建查询计划时是否考虑它在内存中已有的内容，例如：

有 2 个索引在服务请求方面几乎同样出色，但其中一个已经完全或部分在内存中，而另一个没有。

这是计划者考虑的事情，还是从光盘加载索引被认为不太重要，或者很难正确实现这样的功能？

我有两个非常相似的查询：

它们的区别仅在于这部分sq.agreement_id = agreement_idVSsq.agreement_id = 3385

他们的计划是#1慢，#2快

#1 慢

#2 快

为什么在第一种情况下不应用优化？在我看来，优化器可以从中LAST WHERE看出只有一个agreement_id. 所以agreement_id就像常数一样。如果我们将此常量折叠到slow子查询中，它将与子查询相同fast。这是规划师改进的地方吗？

PS。在我对生产的查询中，这导致查询运行 12 秒而不是 20 毫秒

比较：

在第一种情况下，我find_period用相同的参数调用相同的。因为该函数是IMMUTABLE我认为它的计划将被重用（相同的函数，相同的参数，相同的计划），但似乎它没有被重用为什么？

源函数：

并查询：

第一次调用带有EXPLAIN ( ANALYZE, buffers, timing )缓冲区的UPD12808第二次调用是VS 6404：

我目前正在尝试改进 postgres 查询。以下是在 postgres-12.6 上重现我的问题本质的最小设置：

我正在尝试有效地过滤data_node大表引用的小表的所有条目data_entry。预计仅引用节点的子集，并且对于某些安装实例，可能仅引用单个节点。以下查询似乎很自然地完成了这项工作：

在VACUUM ANALYZE两个表上 a 之后，这会产生以下查询计划：

在所示的最小设置中，查询需要几秒钟（在实际的最小应用场景中，需要几分钟），尽管使用较大表上的索引，它应该在不到一毫秒的时间内完成。通过设置SET enable_seqscan = false;，我能够让 postgres 使用“好”的查询计划：

虽然这在我的测试设置中提供了我想要的东西，但全局更改enable_seqscan当然不是生产环境的可行解决方案。

是否有任何“干净”的方法来确保 postgres 使用“好”查询计划或性能相当的计划来过滤引用的小表条目？

当我运行查询并按它过滤agreement_id时很慢，
但是当我按别名过滤时id它很快。（查看查询末尾）

为什么过滤时使用相同的字段会导致不同的执行时间？

链接到explain analyze：

慢1，慢2，快
1，快2

差异从 #20 开始：使用不同索引的地方：
Index Cond: (o.sys_period @> sys_time())VSIndex Cond: (o.agreement_id = 38)

PS。如果我可以联系此功能的开发人员，那就太好了（我还有一个类似的问题）

UPD 我做了一些实验。当我从查询中删除窗口函数时，它在任何情况下都能快速运行。那么为什么窗口函数在某些情况下会停止使用索引呢？如何逃避/解决这个问题？

带有最小测试用例的dbfiddle
服务器版本为 v13.1
完整查询：

有两张桌子

1. customer（分区于customer_batch_id）
2. type_stage（非分区，用于某些计算的阶段表）

type_stage完全为空，没有空值，没有空字符串，我的意思是表没有/零行。当我执行以下查询时，它会扫描每个分区，customer当有更多分区时需要很长时间。

inner join当不存在type_stage将跳过分区序列扫描并减少执行时间的记录时，我们如何跳过此操作。

我尝试像这样在内部连接上添加空检查

但没有行，type_stage它再次给出相同的计划

计划：

我面临以下问题。我需要以编程方式进入我的 vb.net 程序 SQL 的 xml 查询计划以进行查询。然后我将解析它并获取一些信息，但事实并非如此。

通过管理工作室，当我使用以下命令集时，我得到了我想要的结果

问题是，我可以从程序中发送 sql 命令来执行或 sql 命令来获取数据，但一次只能发送一个，这是因为我发送的命令带有特定的自定义类，该类与连接数据库的应用程序服务器连接。我没有直接访问数据库的权限，无法使用我在谷歌搜索时找到的所有方法，或者至少我不太了解这个定制类的所有方法。

我正在尝试使用查询计划缓存找到解决方法。我在想是否有任何方式在查询结束时使用选项以强制 sql 缓存 query_plan，然后使用以下方法获取 xml

我们有一个生产 POSTGRES 9.6 db，有大约 1 亿条记录（LOYALTY）和新表（截至目前<几千）“INFO”

基表（用 django 编写）

问题 1：

这会产生一个缓慢的查询：（全扫描）

在没有 OR 子句的情况下将查询分成 2 个，使其更快 < 1 秒

问题 2：

和

问题 3：

1. 为什么使用 OR 子句使其比使用联合的两个单独查询慢得多？它是否与在 BOTH 表上有条件有关？

2. 为什么它在 QUERY 3 上运行 INDEX 扫描？因为 LOYALTY 表没有 ORDER 作为其索引

3. QUERY 2，即使它进行 INDEX 扫描，如果条件确实说明了索引值是什么（这是单个 order_number？），为什么它没有做比全索引扫描更好的事情？

对于一个非常简单的 SQL 查询生成的查询计划，我遇到了一个非常奇怪的问题。该查询正在搜索全文索引，并返回记录数。

出于某种原因，此 SQL 查询正在对索引产生非聚集扫描，我认为这样做不是最佳选择。我相信对于计数，由于主键在全文索引中，因此只需要聚集查找。

有人会对为什么使用这样的查询计划有任何建议吗？

奇怪的是，由于 SQL 的变体略有不同，有时它使用聚集索引（非常快），有时它使用非聚集搜索。

这是查询：

这是查询计划： https ://i.stack.imgur.com/1XJcf.png如您所见，非集群搜索成本为 51%，加上位图上的 8% 并行度和 15% 哈希匹配。

该表有很多数据。超过 300 万条记录。

非常感谢

编辑：这是计划：https ://www.brentozar.com/pastetheplan/?id=HyiABrg1K

这是表定义：

还有很多外键。

这是唯一的其他索引：