Postgres 8.3 中的位图扫描比索引扫描 Postgres 9.4 快 2 倍？
Posted
技术标签:
【中文标题】Postgres 8.3 中的位图扫描比索引扫描 Postgres 9.4 快 2 倍？【英文标题】：Bitmap scan in Postgres 8.3 2x faster than index scan Postgres 9.4? 【发布时间】：2015-03-19 05:12:37 【问题描述】：在新硬件上将 Postgres 从 8.3.8 升级到 9.4.1。一组有代表性的查询表明，新系统的性能提高了 1 倍到 3 倍。但是，我们的高负载区域之一总是较慢。
EXPLAIN 输出
8.3.8：
Nested Loop (cost=25.78..709859.61 rows=1 width=4) (actual time=14.972..190.591 rows=32 loops=1)
-> Bitmap Heap Scan on prime p (cost=25.78..1626.92 rows=1066 width=4) (actual time=1.567..9.597 rows=10742 loops=1)
Recheck Cond: ((pid = ANY ('28226,53915,83421,82118397,95513866'::integer[])) AND (tid = ANY ('1,2,3'::integer[])))
Filter: (NOT deleted)
-> Bitmap Index Scan on FOO_IDX1 (cost=0.00..25.73 rows=1066 width=0) (actual time=1.144..1.144 rows=10742 loops=1)
Index Cond: ((pid = ANY ('28226,53915,83421,82118397,95513866'::integer[])) AND (deleted = false) AND (tid = ANY ('1,2,3'::integer[])))
-> Index Scan using FOO_IDX2 on data d (cost=0.00..663.88 rows=1 width=4) (actual time=0.017..0.017 rows=0 loops=10742)
Index Cond: (d.pid = p.pid)
Filter: (lower("substring"(d.value, 1, 1000)) ~~ '%something%'::text)
Total runtime: 190.639 ms
9.4.1：
Nested Loop (cost=1.15..335959.94 rows=1 width=4) (actual time=24.712..365.057 rows=32 loops=1)
-> Index Scan using FOO_IDX1 on prime p (cost=0.57..953.17 rows=1033 width=4) (actual time=0.048..13.884 rows=10741 loops=1)
Index Cond: ((pid = ANY ('28226,53915,83421,82118397,95513866'::integer[])) AND (deleted = false) AND (tid = ANY ('1,2,3'::integer[])))
Filter: (NOT deleted)
-> Index Scan using FOO_IDX2 on data d (cost=0.57..324.29 rows=1 width=4) (actual time=0.032..0.032 rows=0 loops=10741)
Index Cond: (pid = p.pid)
Filter: (lower("substring"(value, 1, 1000)) ~~ '%something%'::text)
Rows Removed by Filter: 11
Planning time: 0.940 ms
Execution time: 365.156 ms
索引
…btree (pid);
…btree (lower("substring"(value, 1, 1000)) text_pattern_ops, fid);
…btree (lower("substring"(value, 1, 1000)), fid);
设置
改变以下范围并没有改善这种情况……
checkpoint_completion_target = 0.5
checkpoint_segments = 32
checkpoint_timeout = 30min
cpu_index_tuple_cost = 0.005
cpu_operator_cost = 0.0025
cpu_tuple_cost = 0.01
default_statistics_target = 500 (evaluated 100 to 10000 analyse after each)
effective_cache_size = 288GB
enable_seqscan = off
from_collapse_limit = 8
geqo = off
join_collapse_limit = 8
random_page_cost = 1.0
seq_page_cost = 1.0
shared_buffers = 96GB
work_mem = 64MB
something% 也有类似的结果。
在我们将其搁置几年之前，我想知道是否还有什么可以针对这些重要案例进行优化。
声明
SELECT p.pid
FROM prime p
INNER JOIN data d ON p.pid = d.pid
WHERE LOWER(substring(d.value,1,1000)) LIKE '%something%'
AND p.tid IN (1,2,3)
AND p.deleted = FALSE
AND p.ppid IN (28226, 53915, 83421, 82118397, 95513866)
表定义
经过简化和消毒。
\d prime
Column | Type | Modifiers
---------------+-----------------------------+-------------------------------------------------
pid | integer | not null default nextval('prime_seq'::regclass)
deleted | boolean |
ppid | integer |
tid | integer |
\d data
Column | Type | Modifiers
----------------+---------+------------------------------------------------------
pdid | integer | not null default nextval('data_seq'::regclass)
pid | integer |
value | text |
新的测试结果
我尝试了一系列 default_statistics_target。
default_statistics_target = 100 @ 381 ms
default_statistics_target = 500 @ 387 ms
default_statistics_target = 1000 @ 384 ms
default_statistics_target = 5000 @ 369 ms
（在测试周期之间分析和预热）
此值可以在我们应用程序的其他领域产生重大影响。 500 似乎很理想，5000+ 导致其他区域减速 3 倍到 10 倍。
我们的工具包的设计使得整个数据库应该始终在内存中。
random_page_cost = 1.0 @ 372 ms
random_page_cost = 1.1 @ 372 ms
random_page_cost = 4.0 @ 370 ms
random_page_cost = 10.0 @ 369 ms
使用 enable_bitmapscan = off @ 362 ms（结果与预期的计划相同）
之前我也试过 enable_indexscan = off @ 491 ms（当然触发了不同的计划）
是的，pg 8.3 的计划使用索引和位图索引扫描——我认为这是这个问题的“关键”。
感谢您提供相关文章的链接。
关于列顺序的建议非常有趣。
在我们的规模和增长中，以下模式的最佳字段顺序是什么？
重组已加载表的列顺序以实现收益的最有效方法是什么？
主要有：
integer
text
boolean
boolean
integer
integer
smallint
integer
timestamp without time zone
timestamp without time zone
timestamp without time zone
text
数据有：
integer
integer
integer
text
SELECT pid
FROM data d
JOIN prime p USING (pid)
WHERE LOWER(substring(d.value,1,1000)) LIKE '%something%'
AND p.ppid IN (28226, 53915, 83421, 82118397, 95513866)
AND p.tid IN (1, 2, 3)
AND p.deleted = FALSE;
lower(substring(d.value,1,1000)) = 355 ms
lower(left(d.value,1000)) = 343 ms (~3% faster over multiple tests, I'll take that!)
为了处理未锚定的情况，我们使用运算符类“text_pattern_ops”有第二个索引。
我们之前评估过多列 GIN 索引，但没有实现预期的好处。复杂，因为 A) 在 acl、状态和类似方面要满足多个标准，B) 需要点击“精确短语”，这需要重新检查结果短语。我对长期使用全文方法持乐观态度，到目前为止我们尝试过的食谱并不比 老式 BTREE 方法；还没有。
GIN 试验 1
CREATE EXTENSION btree_gin
CREATE INDEX FOO_IDX3 ON data USING GIN (to_tsvector('simple', lower(left(value, 1000))), pid)
ANALYSE data
SELECT p.pid
FROM prime p
INNER JOIN data d ON p.pid = d.pid
WHERE to_tsvector('simple', lower(left(d.value, 1000))) @@ to_tsquery('simple', 'something')
AND p.tid IN (1,2,3)
AND p.deleted = FALSE
AND p.ppid IN (28226, 53915, 83421, 82118397, 95513866)
Execution time: 1034.866 ms (without phrase recheck)
GIN 试验 2
CREATE EXTENSION pg_trgm
CREATE INDEX FOO_IDX4 ON data USING gin (left(value,1000) gin_trgm_ops, pid);
ANALYSE data
SELECT p.pid
FROM prime p
INNER JOIN data d ON p.pid = d.pid
WHERE left(d.value,1000) LIKE '%Something%'
AND p.tid IN (1,2,3)
AND p.deleted = FALSE
AND p.ppid IN (28226, 53915, 83421, 82118397, 95513866)
Hash Join (cost=2870.42..29050.89 rows=1 width=4) (actual time=668.333..2262.101 rows=32 loops=1)
Hash Cond: (d.pid = p.pid)
-> Bitmap Heap Scan on data d (cost=230.30..26250.04 rows=25716 width=4) (actual time=653.130..2234.736 rows=38659 loops=1)
Recheck Cond: ("left"(value, 1000) ~~ '%Something%'::text)
Rows Removed by Index Recheck: 146677
Heap Blocks: exact=161810
-> Bitmap Index Scan on FOO_IDX4 (cost=0.00..223.87 rows=25716 width=0) (actual time=575.442..575.442 rows=185336 loops=1)
Index Cond: ("left"(value, 1000) ~~ '%Something%'::text)
-> Hash (cost=2604.33..2604.33 rows=2863 width=4) (actual time=15.158..15.158 rows=10741 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 378kB
-> Index Scan using FOO_IDX4 on prime p (cost=0.57..2604.33 rows=2863 width=4) (actual time=0.064..11.737 rows=10741 loops=1)
Index Cond: ((ppid = ANY ('28226,53915,83421,82118397,95513866'::integer[])) AND (deleted = false) AND (tid = ANY ('1,2,3'::integer[])))
Filter: (NOT deleted)
Planning time: 1.861 ms
Execution time: 2262.210 ms
我们已经有一个带有“ppid，deleted，tid”的素数索引，抱歉，最初并不清楚。
【问题讨论】：
你能告诉我们EXPLAIN ANALYZE的结果吗？ 已添加，谢谢弗兰克。 我没有在问题中看到您的实际查询。 （相关部分）表定义也会有所帮助。查看[postgresql-performance]的标签信息以获取说明。
已添加。我不确定更多索引/约束信息在这种情况下是否有用，所以暂时搁置一旁。
@Nothrock：根据您的更新添加了更多内容。
【参考方案1】：
糟糕的查询计划最常见的原因是统计数据或成本设置不能很好地反映现实：
Keep PostgreSQL from sometimes choosing a bad query planrandom_page_cost = 1.0 的设置仅在随机访问实际上与顺序访问一样快时才有意义，这仅在您的数据库完全驻留在 RAM 中时才有意义。具有 80M 和 750M 行表的数据库可能太大了。如果我的假设是正确的，那么稍微提高成本设置可能会解决问题。尝试至少1.1，可能更多。运行测试以找到设置中的最佳位置。
通常我会先运行：
SET enable_bitmapscan = off;
在第 9.4 页的当前会话中，然后再次测试。棘手的部分是您的查询可能同时需要：索引和位图索引扫描。我需要查看查询。
random_page_cost 的极低设置有利于索引扫描而不是位图索引扫描。如果该成本设置具有误导性，您将获得较差的查询计划。
在 dba.SE 上对这个相关问题的回答有更多解释：
Pagination with PostgreSQL 9.3: counting number of pages餐桌设计
您的表格设计已简化，但通常最好不要在整数列之间放置布尔列 *，因为这样会浪费磁盘空间进行填充。更好：
pid | integer | not null default nextval('prime_seq'::regclass)
tid | integer |
deleted | boolean |
这只是一个小改进，但没有任何缺点。
查询
可以通过多种方式改进：
SELECT pid
FROM data d
JOIN prime p USING (pid)
WHERE left(d.value,1000) LIKE '%something%'
AND p.pid IN (28226, 53915, 83421, 82118397, 95513866)
AND p.tid IN (1, 2, 3)
AND p.deleted = FALSE;
left(d.value,1000) 比 substring(d.value,1,1000) 更短更快（需要 pg 9.1+）。
text_pattern_ops 索引仅对与LIKE 匹配的左锚定模式有用。你的表情没有锚定。 （我也看到您也在使用锚定模式。）为此，请使用由附加模块 pg_trgm 提供的三元组 GIN 索引，它的速度大大表，尤其是在 pg 9.4（改进的 GIN 索引）中。
指数
要在下面的 GIN 索引中包含 integer 列 pid，首先安装附加模块 btree_gin，它提供了必要的 GIN 运算符类。 每个数据库运行一次：
CREATE EXTENSION btree_gin;
做一些假设，这对您的查询来说是完美的。 data 上的多列 trigram GIN 索引：
CREATE INDEX data_value_gin_trgm_idx ON data
USING gin (left(value,1000) gin_trgm_ops, pid);
以及prime 上的部分多列索引：
CREATE INDEX prime_pid_tip_idx ON prime (pid, tip)
WHERE deleted = FALSE;
在这里谈数量级。
【讨论】：
【参考方案2】：一种稍微不同的方法，首先通过Common Table Expression (CTE) 从“数据表”中生成最大可能的结果集，然后返回素数以通过 acl、状态等进行细化，将时间从 365 毫秒减少到 142 毫秒（节省 223 毫秒）。这种技术似乎比 8.3 基线更快。
WITH d as (SELECT pid
FROM data
WHERE LOWER(left(value,1000)) LIKE '%something%'
AND fid IN (nnn,nnn,...))
SELECT p.pid FROM d INNER JOIN prime p on p.pid = d.pid
WHERE p.tid IN (1,2,3)
AND p.deleted = FALSE
AND p.ppid IN (28226,53915,83421,82118397,95513866)
计划时间：1.417 毫秒 执行时间：141.508 毫秒
我将进一步评估 CTE 的意外影响。
【讨论】：
以上是关于Postgres 8.3 中的位图扫描比索引扫描 Postgres 9.4 快 2 倍？的主要内容，如果未能解决你的问题，请参考以下文章