集齐了！哪些云提供商支持auto_explain？

不时地，我需要检查一个托管Postgres提供程序是否支持auto_explain扩展，如果支持，他们支持哪些auto_explain参数。由于设置和测试这些工具都很耗时，所以我想为自己创建一个参考，并且认为其他PGer可能也会感兴趣。

我在过去一周进行了测试，但计划保持最新状态。如果您注意到错误，或者提供商更改了他们的支持，请告诉我。

什么是auto_explain?

首先，如果你不熟悉，auto_explain是PostgreSQL作为贡献模块附带的扩展，允许你记录在数据库上运行的查询的执行计划。这对于间歇性变慢的查询特别有用。如果您感兴趣，我们有一个配置auto_explain的指南^[1]，如果您想要更随意的介绍，我们还录制了一段关于它的播客。^[2]

简单介绍

我们简单读一下：

auto_explain模块^[3]提供了一种自动记录慢速语句执行计划的方法，而不必手动运行EXPLAIN。这对于跟踪大型应用程序中未优化的查询特别有帮助。

该模块不提供sql可访问的函数。要使用它，只需将其加载到服务器中。你可以把它加载到一个单独的会话中:

LOAD 'auto_explain';

(你必须是超级用户才能这样做。)更典型的用法是通过在session_preload_libraries或postgresql.conf中的shared_preload_libraries中包含auto_explain将其预加载到部分或所有会话中。这样，无论查询何时发生，您都可以跟踪异常缓慢的查询。当然，这是要付出管理费用的。

配置参数

有几个配置参数控制auto_explain的行为。注意，默认行为是什么都不做，所以如果您想要任何结果，您必须至少设置auto_explain.log_min_duration。

auto_explain.log_min_duration (integer): 
		log_min_duration是将记录语句计划的最小语句执行时间，以毫秒为单位。将其设置为0记录所有计划。
		-1(默认值)禁用计划日志记录。例如，如果将其设置为250ms，那么将记录运行250ms或更长时间的所有语句。
		只有超级用户可以更改此设置。
auto_explain.log_parameter_max_length (integer):
		log_parameter_max_length控制查询参数值的日志记录。值-1(默认值)完整记录参数值。
		0禁用参数值的日志记录。大于零的值将每个参数值截断为那么多字节。只有超级用户可以更改此设置。
auto_explain.log_analyze (boolean) :
		auto_explain.log_analyze导致在记录执行计划时打印EXPLAIN ANALYZE输出，而不仅仅是EXPLAIN输出。
		默认为关闭。只有超级用户可以更改此设置。
auto_explain.log_buffers (boolean) :
		Auto_explain.log_buffers控制在记录执行计划时是否打印缓冲区使用统计信息;
		它相当于EXPLAIN的BUFFERS选项。除非启用auto_explain.log_analyze，否则此参数不起作用。
		默认为关闭。只有超级用户可以更改此设置。
auto_explain.log_wal (boolean):
		auto_explain.log_wal控制在记录执行计划时是否打印WAL使用统计信息;
		它相当于EXPLAIN的WAL选项。除非启用auto_explain.log_analyze，否则此参数不起作用。
		默认为关闭。只有超级用户可以更改此设置。
auto_explain.log_timing (boolean):
		Auto_explain.log_timing控制在记录执行计划时是否打印每个节点的定时信息;
		它相当于EXPLAIN的TIMING选项。在某些系统上，重复读取系统时钟的开销可能会显著降低查询速度，
		因此在只需要实际行数而不需要精确时间时，将此参数设置为off可能会很有用。
		除非启用auto_explain.log_analyze，否则此参数不起作用。默认开启。只有超级用户可以更改此设置。
auto_explain.log_triggers (boolean):
		Auto_explain.log_triggers导致在记录执行计划时包含触发器执行统计信息。
		除非启用auto_explain.log_analyze，否则此参数不起作用。默认为关闭。只有超级用户可以更改此设置。
auto_explain.log_verbose (boolean):
		Auto_explain.log_verbose控制在记录执行计划时是否打印详细信息;它相当于EXPLAIN的VERBOSE选项。
		默认为关闭。只有超级用户可以更改此设置。
auto_explain.log_settings (boolean) :
		Auto_explain.log_settings控制在记录执行计划时是否打印有关修改后的配置选项的信息。
		输出中只包含影响查询规划的值与内置默认值不同的选项。默认为关闭。只有超级用户可以更改此设置。
auto_explain.log_format (enum):
		log_format选择要使用的EXPLAIN输出格式。允许的值为text、xml、json和yaml。
		默认为文本。只有超级用户可以更改此设置。
auto_explain.log_level (enum):
		log_level选择auto_explain记录查询计划的日志级别。
		取值为:DEBUG5、DEBUG4、DEBUG3、DEBUG2、DEBUG1、INFO、NOTICE、WARNING、LOG。
		默认为LOG。只有超级用户可以更改此设置。
auto_explain.log_nested_statements (boolean) :
		Auto_explain.log_nested_statements导致将嵌套语句(在函数内执行的语句)考虑用于日志记录。
		关闭时，只记录顶级查询计划。默认为关闭。只有超级用户可以更改此设置。
auto_explain.sample_rate (real):
		auto_explain。Sample_rate导致auto_explain只解释每个会话中的一小部分语句。
		默认值是1，表示解释所有查询。在嵌套语句的情况下，要么全部解释，要么不解释。
		只有超级用户可以更改此设置。

请注意当启用参数: auto_explain.log_analyze时，执行的所有语句都会按计划节点计时，无论它们运行的时间是否长到足以记录日志。这可能会对性能产生极其负面的影响。关闭auto_explain.log_timing可以改善性能成本，但代价是获得更少的信息。

在通常的使用中，这些参数是在postgresql.conf中设置的，尽管超级用户可以在他们自己的会话中动态地修改它们。典型用法是:

cat >> postgresql.conf <<EOF
session_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = '3ms'
EOF

使用实例

实例1:

postgres=# LOAD 'auto_explain';
postgres=# SET auto_explain.log_min_duration = 0;
postgres=# SET auto_explain.log_analyze = true;
postgres=# SELECT count(*)
           FROM pg_class, pg_index
           WHERE oid = indrelid AND indisunique;

结果会产生如下的log:

LOG:  duration: 3.651 ms  plan:
  Query Text: SELECT count(*)
              FROM pg_class, pg_index
              WHERE oid = indrelid AND indisunique;
  Aggregate  (cost=16.79..16.80 rows=1 width=0) (actual time=3.626..3.627 rows=1 loops=1)
    ->  Hash Join  (cost=4.17..16.55 rows=92 width=0) (actual time=3.349..3.594 rows=92 loops=1)
          Hash Cond: (pg_class.oid = pg_index.indrelid)
          ->  Seq Scan on pg_class  (cost=0.00..9.55 rows=255 width=4) (actual time=0.016..0.140 rows=255 loops=1)
          ->  Hash  (cost=3.02..3.02 rows=92 width=4) (actual time=3.238..3.238 rows=92 loops=1)
                Buckets: 1024  Batches: 1  Memory Usage: 4kB
                ->  Seq Scan on pg_index  (cost=0.00..3.02 rows=92 width=4) (actual time=0.008..3.187 rows=92 loops=1)
                      Filter: indisunique

实例2:

配置参数并restart:

cat >> postgresql.conf <<EOF
session_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = '3ms'
EOF

pg_ctl restart

postgres=# create table t2(id int, col2 varchar(32));
CREATE TABLE
postgres=# insert into t2 select n, 'test ' || n from generate_series(1, 200000) as n;
INSERT 0 200000
postgres=#
postgres=#
postgres=#
postgres=# select * from t2 where col2 not in (select col2 from t2);
....
-- 这条语句花了很长很长时间
postgres=# select * from t2 where id not in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

看看对应产生的log:

2024-07-28 08:57:08.651 CST [4044] LOG:  duration: 248.613 ms  plan:
        Query Text: insert into t2 select n, 'test ' || n from generate_series(1, 200000) as n;
        Insert on t2  (cost=0.00..4000.00 rows=0 width=0)
          ->  Function Scan on generate_series n  (cost=0.00..4000.00 rows=200000 width=86)

......
2024-07-28 09:00:16.756 CST [4618] LOG:  connection received: host=[local]
2024-07-28 09:00:16.756 CST [4044] ERROR:  canceling statement due to user request
2024-07-28 09:00:16.756 CST [4044] STATEMENT:  select * from t2 where col2 not in (select col2 from t2);
2024-07-28 09:00:16.756 CST [4074] FATAL:  terminating background worker "parallel worker" due to administrator command
2024-07-28 09:00:16.756 CST [4074] STATEMENT:  select * from t2 where col2 not in (select col2 from t2);
2024-07-28 09:00:16.757 CST [3960] LOG:  background worker "parallel worker" (PID 4074) exited with exit code 1

2024-07-28 09:00:47.701 CST [4044] STATEMENT:  select * from t2 where id not in values(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
2024-07-28 09:00:55.373 CST [4044] LOG:  duration: 49.305 ms  plan:
        Query Text: select * from t2 where id not in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
        Seq Scan on t2  (cost=0.00..5582.00 rows=199990 width=15)
          Filter: (id <> ALL ('{1,2,3,4,5,6,7,8,9,10}'::integer[]))

云提供商支持auto_explain简介

下面是到目前为止我研究过的提供程序的摘要，并简要介绍了它们是否支持auto_explain，如果支持，它有多少个参数。

欢迎任何更正、补充或更新。下面，我为每个提供程序记录了更多信息，包括它们允许配置的参数。

Amazon RDS

好消息是，Amazon RDS支持auto_explain^[4]。除了较新的参数和log_level之外，大多数参数都可以配置。

Amazon的Aurora PostgreSQL也支持auto_explain使用相同的参数，外加一个专有参数auto_explain.hash^[5]。

Google Cloud SQL

好消息是，Google Cloud SQL支持auto_explain^[6]。除了不是特别有用的log_parameter_max_length之外，所有参数都可以配置。

Google的AlloyDB^[7]也支持auto_explain参数。

Azure Database

好消息是，Azure数据库支持auto_explain^[8]。除了不是特别有用的log_parameter_max_length之外，所有参数都可以配置。

然而，在Azure Cosmos DB上似乎不支持auto_explain。

Crunchy Bridge

好消息是，Crunchy Bridge支持auto_explain^[9]。除了较新的参数和log_level之外，大多数参数都可以配置。

Timescale Cloud

好消息，在Timescale Cloud中支持auto_explain，并且每个参数都可以配置!

Aiven

不幸的是，在PostgreSQL的Aiven中不支持auto_explain，至少在没有aiven_extras扩展^[10]的情况下(即使是在每个会话的基础上)。

Digital Ocean

不幸的是，auto_explain在Digital Ocean中不支持^[11]。

EDB Big Animal

好消息，在Big Animal中支持auto_explain^[12]，并且每个参数都可以配置!

Heroku

好消息是，Heroku Postgres支持auto_explain^[13]。参数的一个子集是可配置的。

Neon

不幸的是，Neon不支持auto_explain^[14]。

ScaleGrid

好消息是，ScaleGrid支持auto_explain^[15]，它甚至在默认情况下是开启的。然而，虽然默认情况下有几个参数是开启的，但大多数参数是不可配置的。

Supabase

不幸的是，在Supabase中不支持auto_explain^[16]。

Tembo

好消息，Tembo支持auto_explain。参数必须在“附加配置”中手动输入，但这确实意味着所有参数都支持!

总结

遗憾的是，尽管auto_explain还在贡献中，但相当数量的托管服务还不支持它。然而，一大堆这样做，其中许多也提供了体面的覆盖参数!

希望随着时间的推移，支持会越来越多。如果您注意到某个提供商已经改变了他们的支持，或者您使用的是我们上面没有提到的提供商，那么很高兴听到您的消息。原文在：https://www.pgmustard.com/blog/which-cloud-providers-support-auto-explain

参考资料