与我的笔记本电脑相比，Google SQL 上的 Postgres 查询的性能急剧下降。为什么？答案

【问题标题】：Dramatic decrease in performance for Postgres query on Google SQL compared to my laptop. Why?与我的笔记本电脑相比，Google SQL 上的 Postgres 查询的性能急剧下降。为什么？
【发布时间】：2021-05-14 19:35:42
【问题描述】：

在具有大约 1M 条记录的表上运行的相当复杂的（取决于标准）查询。创建一些临时表并构建数组和jsonb。

在本地主机上，我平均得到 2.5 秒。在 Google SQL 上，我得到 17-19 秒。

注意：

其他查询，如简单选择，在服务器上比在本地上要快。应该如此。
我确实运行了 Vacuum，重建了所有索引，检查了挂起过程。一切顺利。
我玩过资源。创建了一个具有 8 个 VCPU 和 16Gb 内存的实例。结果几乎相同。
我检查了 proc、mem、disc。没问题。

这是来自explain analyse最慢查询的结果。这里是本地人

可能是什么？

可能与this 重复，但未得到答复，已使用 2 年且没有标签。我会试试运气的。

L.E.解释分析文本中的详细内容

Update on public.customers  (cost=30.38..207.32 rows=127 width=104) (actual time=13105.151..13105.154 rows=0 loops=1)
Planning Time: 1.852 ms
Execution Time: 13105.306 ms
  ->  Hash Join  (cost=30.38..207.32 rows=127 width=104) (actual time=316.371..13091.937 rows=42 loops=1)
"        Output: customers.id, customers.company_id, customers.sap_id, customers.parent_sap_id, jsonb_set(customers.stats, '{consolidatedSales}'::text[], jsonb_build_array(calculateconsolidatedstats(customers.id, customers.sap_id, ((date_part('year'::text, (CURRENT_DATE)::timestamp without time zone) - '2'::double precision))::integer), calculateconsolidatedstats(customers.id, customers.sap_id, ((date_part('year'::text, (CURRENT_DATE)::timestamp without time zone) - '1'::double precision))::integer), calculateconsolidatedstats(customers.id, customers.sap_id, (date_part('year'::text, (CURRENT_DATE)::timestamp without time zone))::integer)), true), customers.tags, customers.account_manager_id, customers.created_by_id, customers.customer_status_id, customers.created_at, customers.updated_at, customers.ctid, parents_with_sales.ctid"
        Inner Unique: true
        Hash Cond: (customers.id = parents_with_sales.id)
        ->  Seq Scan on public.customers  (cost=0.00..74.54 rows=254 width=924) (actual time=0.021..0.419 rows=254 loops=1)
        ->  Hash  (cost=27.88..27.88 rows=200 width=10) (actual time=0.086..0.088 rows=42 loops=1)
"              Output: parents_with_sales.ctid, parents_with_sales.id"
"              Output: customers.id, customers.company_id, customers.sap_id, customers.parent_sap_id, customers.stats, customers.tags, customers.account_manager_id, customers.created_by_id, customers.customer_status_id, customers.created_at, customers.updated_at, customers.ctid"
              Buckets: 1024  Batches: 1  Memory Usage: 10kB
              ->  HashAggregate  (cost=25.88..27.88 rows=200 width=10) (actual time=0.059..0.072 rows=42 loops=1)
"                    Output: parents_with_sales.ctid, parents_with_sales.id"
                    Group Key: parents_with_sales.id
                    Batches: 1  Memory Usage: 40kB
                    ->  Seq Scan on pg_temp_7.parents_with_sales  (cost=0.00..22.70 rows=1270 width=10) (actual time=0.010..0.019 rows=42 loops=1)
"                          Output: parents_with_sales.ctid, parents_with_sales.id"

需要 12 秒的罪魁祸首查询的 Cloud Logging 结果

【问题讨论】：

1) explain (analyse, verbose, buffers, settings) ... 了解更多详情； 2) 请输入文本。
@marian.vladoi：这将如何与 PostgreSQL 一起使用？
我会推荐给Monitor slow queries in PosgreSQL with Cloud Logging and Monitoring，以便更好地了解性能。
@Abelisto - 完成。见 L.E.
@marian.vladoi - 完成。不知道它有什么帮助，但我添加了它。

标签： sql postgresql performance google-cloud-sql

【解决方案1】：

问题解决了。问题出在版本中。

短版：在 v11 上部署，一切恢复正常。服务器比我的笔记本电脑快，应该的。

长版：

尝试在 VMS（2 vcpu，4Gb ram）中进行全新安装。我得到了 20 多秒，甚至比托管实例更差。将资源增加到 16proc、64Gb ram 和 500Gb SSD（用于 IO），所有这些都是该区域允许的最大值。结果令人惊讶……时间增加到 25 秒。
去了 Digital Ocean：托管实例，1VCPU 和 3.6 Gb Ram - 12 秒（这家伙太棒了！）。更好，但仍然表现不佳。将实例资源增加到允许的最大值 - 没有明显改善。
没有尝试过 AWS。做实验太贵了。 :-)
最后我发现我本地安装的版本是11而不是我想的12。回到 gcloud 并尝试使用运行 v11 的实例和......奇迹。像魅力一样工作。

将在其他时间挖掘“为什么 v12 和 v13 慢得多”。

【讨论】：