与我的笔记本电脑相比，Postgres在Google SQL上的查询性能大幅下降。为什么？

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

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

注:

其他查询，如简单选择，在服务器上比在本地上更快。应该如此

我确实运行了真空，重建了所有的索引，检查了悬挂过程。一切都好

我玩弄资源。创建了一个具有8个VCPU和16Gb Ram的实例。几乎相同的结果

我检查了进程、内存和光盘。没问题

以下是最慢查询的

explain analysis

结果。 这里是本地的

可能是什么

可能重复，但未回答，有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秒的罪魁祸首查询的云日志记录结果 问题已解决。 问题在版本中

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

长版本：

• 尝试在VMS（2个vcpu，4Gb ram）中重新安装。我得到了20多秒，甚至比托管实例中的情况还要糟糕。将资源增加到16proc、64Gb ram和500Gb SSD（用于IO），所有这些都是该区域允许的最大值。结果是惊人的。。。时间增加到25秒
• 转到数字海洋：托管实例、1VCPU和3.6GB Ram—12秒（这家伙太棒了！）。更好，但仍然表现不佳。将实例资源增加到允许的最大值-没有明显的改进
• 没有尝试AWS。实验太贵了。：-）
• 最后，我意识到我在本地安装的版本是11，而不是我想的12。返回到gcloud并尝试使用运行v11的实例，然后。。。奇迹。工作起来很有魅力

---

将在其他时间深入研究“为什么v12和v13的速度如此之慢”

1）

解释（分析、详细、缓冲、设置）…

了解更多细节；2） 请以文本形式生成结果。@marian.vladoi:这对PostgreSQL有何作用？我建议使用，以便更好地理解性能。@Abelisto-done。见L.E.@marian.vladoi-完成。不知道它有什么帮助，但我补充说。