【发布时间】:2017-06-07 12:06:16
【问题描述】:
我已经设置了 Postgres 9.6 并检查了并行查询正在工作的随机整数的大表。 但是,对另一个表的 XML 列的简单 XPath 查询始终是顺序的。在 Postgres 中,这两个 XPath 函数都被标记为并行安全的。我试图改变 XPath 成本,因此预期成本猛增,但并没有改变任何东西。 我错过了什么?
示例表 DDL:
CREATE TABLE "test_table" ("xml" XML );
查询示例:
SELECT xpath('/a', "xml") FROM "test_table";
示例数据:
<a></a>。
请注意,真实数据包含大小为 10-1000kB 的 XML。
> select pg_size_pretty(pg_total_relation_size('test_table'));
28 MB
> explain (analyze, verbose, buffers) select xpath('/a', "xml") from test_table;
Seq Scan on public.test_table (cost=0.00..64042.60 rows=2560 width=32) (actual time=1.420..4527.061 rows=2560 loops=1)
Output: xpath('/a'::text, xml, '{}'::text[])
Buffers: shared hit=10588
Planning time: 0.058 ms
Execution time: 4529.503 ms
【问题讨论】:
-
请发布您正在运行的查询,最好是表结构(可以简化)和一些示例数据。 -- 请注意,1 个函数(不是并行安全的)足以选择退出整个查询的并行性。
-
嗯,没有比这更简单的了,但我按照你的要求添加了它。
-
请Edit您的问题并添加使用
explain (analyze, verbose)生成的执行计划。 Formatted text 请no screen shots -
表可能太小而无法考虑进行并行 seq 扫描。 default minimum size 是 8MB。但是,对只有 2500 行的表进行 3 秒的 seq 扫描太慢了。那是一张非常宽的桌子吗?即它有很多列吗?使用
explain (analyze, buffers)可能会给出提示 -
尝试删除
parallel_tuple_cost和parallel_setup_cost的值。将它们设置为零应该使计划者选择并行计划。为您的查询计时,看看计划者是否真的弄错了。根据我的经验,parallel_tuple_cost可能会因为默认值 (0.1) 太高而超出返回大量行的查询的估计值。
标签: postgresql xpath postgresql-parallel-query