太长不看

• 普段使ってるLinuxマシンで、PostgreSQL 11〜16を動かして、Star Schema Benchmarkを走行させた。

• PostgreSQL 13から14にかけて、パラレルクエリが高速化している。

• q4.3で使用されるパラレルワーカー数が減る問題については、依然として残ったまま。

上記とは別に、q4.3はPostgreSQL 16で遅くなってしまっている(ように見える)

首先

圣诞倒数日历

这是 PostgreSQL Advent Calendar 2023 的第一系列的第6天的文章。
昨天由そーだい (@soudai2025) 负责。

順便一提，在我的生活中，這是我第一次參加Advent Calendar。

这篇文章是关于…

在某组织活动期间，我计划每年举行一次惯例的验证。然而，大约两年前的一个偶然事件导致我触怒了众神，结果不仅未能使其成为惯例，还不得不离开该组织。所以我只是个人尝试了一下，没有任何结果。需要注意的是，众神的愤怒至今没有平息，如果我惹恼他们了，可能会被彻底抹去。

什么是并行查询？

并行查询是一种处理方法，通过将一个查询分配给多个线程或进程并行处理，以比单线程/进程更快地执行查询。

在PostgreSQL中的并行查询

在PostgreSQL中，并行查询是通过多进程进行并行处理的。
选择并行查询的条件是，目标表的大小较大，并且执行计划仅由(PostgreSQL 15版本)此页面中所描述的处理组成，并且不存在无法使用并行查询的情况。

一般来说，当对大型表进行SELECT语句时，有可能会触发并行查询，这可能是因为没有使用索引或使用了B-Tree索引。

在这种情况下，无论是通过并发查询还是通常的非并发查询都要计算成本并加以考虑，只有当成本最小且被判断为最小时，才会作为并发查询执行。

执行的并行度取决于与搜索相关的表格大小。请参考某组织的成果物中的记录，以了解更多信息。2

性能验证

什么是星型模型基准测试？

我们在这次验证中使用了星型模式基准测试。

星型模式基准测试是一种用于评估在包括商业智能和在线分析处理（OLAP）在内的关系型数据库管理系统（RDBMS）性能的基准测试方法。它主要以销售数据（大量数据表）如POS数据和电子商务数据为中心，并围绕着客户信息和店铺信息（相对较小的数据量）进行分析，通过适当的连接和中心表查询结果。可能是因为图形展示上看起来像星星，所以称之为具有这种结构的Star Schema。有关详细信息，请参阅某组织成果中关于Star Schema Benchmark的说明。

测量的要求

以下是測試對象的機器。

• 自作マシン (aka ゲーミングPostgreSQLサーバ)

CPU: AMD Ryzen 7 2700X

8 Cores, 16 Threads

メモリ: 64GB (OCメモリ DDR4-3200相当)
OS: Debian sid (Kernel 6.5.13 (linux-image-6.5.0-5-amd64))

我们使用的软件如下所示。

• Star Schema Benchmark3

• これは、pg_ssb_runのREADME.mdとSSBの実行方法に記載されているものに準拠。

Scale Factor: 70G
データ生成プログラム: こちら

ベンチマーク用クエリ: この論文から抜粋
ベンチマーク走行プログラム:pg_ssb_run

検証したPostgreSQLのバージョン毎に5回走行して、平均値を記録とする。

PostgreSQL
すべて、ソースコードからビルドしたもの

gccのバージョン
gcc (Debian 13.2.0-7) 13.2.0

バージョン
カッコ内は、各STABLEブランチのコミットIDを示す。
すべて、zipやtar.gzで配布されている地点以降のコミットID。

11.224

12.17相当 (5d40b3c4)
13.13相当 (3c49fa2a)
14.10相当 (e846fc49)
15.5相当 (15d48592)
16.1相当 (267f33f6)

パラメータ
デフォルト値から変更しているもののみ記載
鍵となるパラメータは太字で表記

shared_buffers = 48GB
effective_cache_size = 48GB
work_mem = 8GB
maintenance_work_mem = 2GB
wal_buffers = 16MB
max_wal_size = 16GB
min_wal_size = 4GB
checkpoint_completion_target = 0.9
max_worker_processes = 12
max_parallel_maintenance_workers = 2

max_parallel_workers_per_gather = 7 5

max_parallel_workers = 7 5

jit = off

将基准数据放置在桌子上后，结果如下所示。
中心表为 lineorder 表，大小为41GB。

=# \d+
                                   リレーション一覧
 スキーマ |   名前    |  タイプ  | 所有者 | 永続性 | アクセスメソッド | サイズ | 説明 
----------+-----------+----------+--------+--------+------------------+--------+------
 public   | customer  | テーブル | taiki  | 永続   | heap             | 250 MB | 
 public   | date      | テーブル | taiki  | 永続   | heap             | 336 kB | 
 public   | lineorder | テーブル | taiki  | 永続   | heap             | 41 GB  | 
 public   | part      | テーブル | taiki  | 永続   | heap             | 157 MB | 
 public   | supplier  | テーブル | taiki  | 永続   | heap             | 76 MB  | 
(5 行)

在进行测量时，先使用 pg_prewarm 将上述所有表的所有数据加载到 PostgreSQL 的共享缓冲区中，然后再进行测量。

测量结果

花了多少時間

首先，以下展示所需时间的测量结果。单位为秒。

另外，以下展示了将上述表格制作成的图表。

q4.3的平行工作者数量

让我们确认一下一直困扰着我们的问题：在Q4.3中，并行工作者数量减少的问题是否已经得到解决。

下面是一个表格，其中列出了从实际执行计划中提取出来的计划使用的并行工作人数和实际使用的工作人数。

根据这次设定的情况，如果修正了的话，至少计划会达到7个，但是现在看来，还没有进行修正。

以下是使用pev2工具在PostgreSQL 16.1中对q4.3的执行计划进行可视化的结果。
在最左边的是customer表，因此整个并行任务的数量受其影响。

感受

在PostgreSQL 14中进行了优化以提高速度。

从PostgreSQL 13到14，所需时间显著减少。
可以看出在并行查询方面有了重大改进。
实际上，PostgreSQL 14的发布说明中也有这样的描述。

可能是一个困难的问题吗？

从PostgreSQL 9.6开始，我们观察到在第4.3个问题中，并发工作者数量的减少。虽然我们已经确定了直接的原因代码，但在某些数据集上无法再现该问题，这也可以解释为查询规划器的精度问题。

所以，就算在社区中提出这个问题，我个人对于讨论是否会简单地朝着“修正这段代码就没问题！”这个方向开展，抱有些许怀疑。
在提出这个问题给社区之前，我想先争取到澤田先生或藤井先生这样的支持者。

此外，从图表上来看，与前述问题无关，但在PostgreSQL 16中，q4.3所需的时间却回到了与PostgreSQL 11相当的水平。这可能是由于在PostgreSQL 16中新增的部分导致的。这是需要进一步测试的部分。

最后

这次我在 PostgreSQL 中使用星型模式基准测试来评估并行查询的性能。因为有一些需要仔细调查的地方，所以如果有时间的话，我很想进行调查。

如果您有一台性能良好的机器可以运行PostgreSQL，为什么不尝试使用这个基准测试来评估和调查PostgreSQL的性能，并展示自己机器的能力呢？

明天将由 @jun2 担任。