python - LIMIT 0 的查询性能

Question

我的应用程序将接收用户提交的选择查询，而不是执行它并获得完整的结果集，在这个阶段，它只需要列名和类型。

用户将是数据分析师，所以我预计会提交很多毛茸茸的查询。随着数据量的增长，提交的查询将保留在应用程序中并经常被评估(基于触发器和 cron 的混合)。

客户端应用程序是用 python 和 sqlalchemy-core 编写的，用于与数据库交互。

目前，我在查询末尾附加一个 LIMIT 0 以仅获取结果元数据。到目前为止，这给了我可接受的结果

例子:

要检查的查询:

SELECT * FROM users

探测查询

SELECT * FROM users LIMIT 0

EXPLAIN ANALYZE 返回以下结果:

Limit  (cost=0.00..0.11 rows=1 width=646) (actual time=0.001..0.001 rows=0 loops=1)
  ->  Seq Scan on users  (cost=0.00..22457.28 rows=207728 width=646) (never executed)
Planning time: 0.067 ms
Execution time: 0.025 ms

请注意，Seq Scan on users 有一个注释(从未执行)。

接下来我在一个更复杂的查询上尝试了 LIMIT 0，结果如下:

EXPLAIN ANALYZE
WITH blah AS (
SELECT * 
FROM users 
JOIN reservation 
  ON reservation.user_id = users.id
)
SELECT * FROM blah 
LIMIT 0

-- result:
Limit  (cost=482925.94..482925.96 rows=1 width=1955) (actual time=0.001..0.001 rows=0 loops=1)
  CTE blah
    ->  Hash Join  (cost=42094.88..482925.94 rows=1563750 width=1418) (never executed)
          Hash Cond: (reservation.user_id = users.id)
          ->  Seq Scan on reservation  (cost=0.00..96868.50 rows=1563750 width=772) (never executed)
          ->  Hash  (cost=22457.28..22457.28 rows=207728 width=646) (never executed)
                ->  Seq Scan on users  (cost=0.00..22457.28 rows=207728 width=646) (never executed)
  ->  CTE Scan on blah  (cost=0.00..31275.00 rows=1563750 width=1955) (never executed)
Planning time: 8.284 ms
Execution time: 0.113 ms

同样，唯一的成本是计划时间和更短的执行时间。

问题:

1. 将总时间的上限假设为计划时间的两倍是否安全？

2. 在 Postgresql 中，我一直认为 CTE 是优化围栏。但是，对于 LIMIT 0，CTE 似乎没有实现 (从未执行)。这是我可以依靠的行为吗(9.5+)

3. 是否有更简单/更有效的方法来获取选择查询的元数据？ 如果我可以假设上面的第 1 点，那么这不是一个非常重要的问题

4. 有趣的是，您在 SELECT 查询上观察到的最大计划时间是多少？

5. 我相当确定，即使基础表中的数据量增加，我也可以假设同一查询的计划时间相似。有没有这种情况不成立的情况？

Answer 1

1. 我认为在大多数情况下，执行时间将大致保持不变，数据修改 CTE 除外(见下文)。

2. 如果 CTE 从未被使用过，它就不会被执行。此规则的异常(exception)情况是 CTE 中是否存在数据修改语句；在这种情况下，始终执行 CTE。

3. 我认为在 PL/Python 中没有更好的方法。如果您编写一个 C 函数，您可能可以准备该语句，然后获取其结果列，但这也可能很重要。

4. 没有很棒的故事可以分享...

5. 计划时间与表的大小无关。