Question

我正在使用Postgres中的HackerNews数据集。大约有17M行，大约14.5M是评论，大约2.5M是故事。有一个非常活跃的用户名为“rbanffy”，有25k提交，大约相同的分裂故事/评论。 “by”和“type”都有单独的索引。

我有一个问题：

SELECT *
FROM "hn_items"
WHERE by = 'rbanffy'
and type = 'story'
ORDER BY id DESC
LIMIT 20 OFFSET 0

快速运行（它使用'by'索引）。如果我将类型更改为“注释”，则它非常慢。从解释中，它不使用任何索引并进行扫描。

Limit  (cost=0.56..56948.32 rows=20 width=1937)
  ->  Index Scan using hn_items_pkey on hn_items  (cost=0.56..45823012.32 rows=16093 width=1937)
        Filter: (((by)::text = 'rbanffy'::text) AND ((type)::text = 'comment'::text))

如果我将查询更改为type||''='comment'，那么它将使用'by'索引并快速执行。

为什么会这样？我从https://stackoverflow.com/a/309814/214545了解到，必须做这样的黑客行为意味着某些事情是错误的。但我不知道是什么。

编辑：
这是type ='story'

的解释

Limit  (cost=72553.07..72553.12 rows=20 width=1255)
  ->  Sort  (cost=72553.07..72561.25 rows=3271 width=1255)
        Sort Key: id DESC
        ->  Bitmap Heap Scan on hn_items  (cost=814.59..72466.03 rows=3271 width=1255)
              Recheck Cond: ((by)::text = 'rbanffy'::text)
              Filter: ((type)::text = 'story'::text)
              ->  Bitmap Index Scan on hn_items_by_index  (cost=0.00..813.77 rows=19361 width=0)
                    Index Cond: ((by)::text = 'rbanffy'::text)

编辑：解释（分析，缓冲）

Limit  (cost=0.56..59510.10 rows=20 width=1255) (actual time=20.856..545.282 rows=20 loops=1)
  Buffers: shared hit=21597 read=2658 dirtied=32
  ->  Index Scan using hn_items_pkey on hn_items  (cost=0.56..47780210.70 rows=16058 width=1255) (actual time=20.855..545.271 rows=20 loops=1)
        Filter: (((by)::text = 'rbanffy'::text) AND ((type)::text = 'comment'::text))
        Rows Removed by Filter: 46798
        Buffers: shared hit=21597 read=2658 dirtied=32
Planning time: 0.173 ms
Execution time: 545.318 ms

编辑：type='story'

的EXPLAIN（ANALYZE，BUFFERS）

Limit  (cost=72553.07..72553.12 rows=20 width=1255) (actual time=44.121..44.127 rows=20 loops=1)
  Buffers: shared hit=20137
  ->  Sort  (cost=72553.07..72561.25 rows=3271 width=1255) (actual time=44.120..44.123 rows=20 loops=1)
        Sort Key: id DESC
        Sort Method: top-N heapsort  Memory: 42kB
        Buffers: shared hit=20137
        ->  Bitmap Heap Scan on hn_items  (cost=814.59..72466.03 rows=3271 width=1255) (actual time=6.778..37.774 rows=11630 loops=1)
              Recheck Cond: ((by)::text = 'rbanffy'::text)
              Filter: ((type)::text = 'story'::text)
              Rows Removed by Filter: 12587
              Heap Blocks: exact=19985
              Buffers: shared hit=20137
              ->  Bitmap Index Scan on hn_items_by_index  (cost=0.00..813.77 rows=19361 width=0) (actual time=3.812..3.812 rows=24387 loops=1)
                    Index Cond: ((by)::text = 'rbanffy'::text)
                    Buffers: shared hit=152
Planning time: 0.156 ms
Execution time: 44.422 ms

编辑：最新的测试结果我正在玩type='comment'查询，并注意到如果将限制更改为更高的数字（如100），它会使用by索引。我玩了这些值，直到我发现关键数字为'47'。如果我的限制为47，则使用by索引，如果我的限制为46，则为全扫描。我认为这个数字并不神奇，恰好是我的数据集或其他一些我不知道的变量的阈值。我不知道这是否有帮助。

Answer 1

由于comment有很多rbanffy s，PostgreSQL认为如果按照ORDER BY子句隐含的顺序搜索表，它会足够快（可以使用主键索引）直到找到20行符合搜索条件。

不幸的是，这个家伙最近变得懒惰 - 无论如何，PostgreSQL必须扫描46798最高id s直到找到它的20次点击。（你真的不应该删除让我困惑的Backwards。）

解决这个问题的最好方法是混淆PostgreSQL，以便它不会选择主键索引，也许是这样：

SELECT *
FROM (SELECT * FROM hn_items
      WHERE by = 'rbanffy'
        AND type = 'comment'
      OFFSET 0) q
ORDER BY id DESC
LIMIT 20;

为什么postgres会进行表扫描而不是使用我的索引？

1 个答案: