performance - Postgres 8.3 中的位图扫描比索引扫描 Postgres 9.4 快 2 倍？

Question

在新硬件上将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);

设置

改变以下范围并没有改善这种情况……</p>

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;

在这种方法中没有观察到可测量的差异，相同的计划（+/- 5 毫秒）
我们一般先尝试缩小data中搜索记录的范围，先用prime来检查acl、status等（prime是大小的1/10）

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 方法更快或更稳定；然而。

杜松子酒试验 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)

杜松子酒试验 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”的素数索引，抱歉，最初并不清楚。

score 2 · Accepted Answer

糟糕的查询计划最常见的原因是统计数据或成本设置不能很好地代表现实：

防止 PostgreSQL 有时选择错误的查询计划

仅当随机访问实际上与顺序访问一样快时，设置random_page_cost = 1.0才有意义，这仅在您的数据库完全驻留在 RAM 中时才成立。具有 80M 和 750M 行表的数据库可能太大了。如果我的假设是正确的，那么稍微提高成本设置可能会解决问题。至少尝试1.1，可能更多。运行测试以找到设置中的最佳位置。

通常我会先运行：

SET enable_bitmapscan = off;

在 pg 9.4 的当前会话中，然后再次测试。棘手的部分是您的查询可能同时需要：索引和位图索引扫描。我需要查看查询。

极低的设置random_page_cost有利于索引扫描而不是位图索引扫描。如果该成本设置具有误导性，您将获得较差的查询计划。

在 dba.SE 上对这个相关问题的回答有更多解释：

PostgreSQL 9.3 分页：计算页数

餐桌设计

您的表设计已简化，但通常最好不要在整数列之间放置布尔列 *，因为这样会浪费磁盘空间来填充。更好的：

pid           | integer  | not null default nextval('prime_seq'::regclass)
tid           | integer  | 
deleted       | boolean  |

在 PostgreSQL 中计算和节省空间

这只是一个小的改进，但它没有缺点。

询问

可以通过多种方式改进：

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。你的表情没有锚定。（我也看到您正在使用锚定模式。）为此，请使用由附加模块提供的 trigram GIN 索引，该模块pg_trgm在大表中速度非常快，尤其是在 pg 9.4（改进的 GIN 索引）中。
- PostgreSQL LIKE 查询性能变化
- 在 PostgreSQL 中使用 LIKE、SIMILAR TO 或正则表达式进行模式匹配

指数

要将integer列包含pid在下面的 GIN 索引中，首先安装附加模块btree_gin，它提供了必要的 GIN 运算符类。每个数据库运行一次：

CREATE EXTENSION btree_gin;

做出一些假设，这对您的查询来说是完美的。上的多列三元组 GIN 索引data：

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;

在这里谈论数量级。

score 0 · Accepted Answer

一种稍微不同的方法，首先通过公用表表达式(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 ms
执行时间：141.508 ms

我将进一步评估 CTE 的意外影响。

performance - Postgres 8.3 中的位图扫描比索引扫描 Postgres 9.4 快 2 倍？

EXPLAIN输出

索引

设置

陈述

表定义

新的测试结果

2 回答 2

餐桌设计

询问

指数

Related

Reference

`EXPLAIN`输出