Question

我正在优化Postgres表，该表存储来自日志文件的信息。

以下是查询：

SELECT c_ip as ip
     , x_ctx as file_name
     , date_time
     , live
     , c_user_agent as user_agent 
FROM events 
WHERE x_event = 'play' 
  AND date = '2012-12-01' 
  AND username = 'testing'

x_event，date和username上有b-tree索引。在此表中，有大约2500万行。现在查询大约需要20-25（更正，更像是40）秒，并返回143,000行。

预计到时间了吗？我原以为它因索引会更快。也许是因为它必须通过大量的数据？

编辑：这是EXPLAIN ANALYZE：

Bitmap Heap Scan on events  (cost=251347.32..373829.74 rows=35190 width=56) (actual time=5768.409..6124.313 rows=143061 loops=1)
  Recheck Cond: ((date = '2012-12-01'::date) AND (username = 'testing'::text) AND (x_event = 'play'::text))
  ->  BitmapAnd  (cost=251347.32..251347.32 rows=35190 width=0) (actual time=5762.083..5762.083 rows=0 loops=1)
        ->  Bitmap Index Scan on index_events_fresh_date  (cost=0.00..10247.04 rows=554137 width=0) (actual time=57.568..57.568 rows=572221 loops=1)
              Index Cond: (date = '2012-12-01'::date)
        ->  Bitmap Index Scan on index_events_fresh_username  (cost=0.00..116960.55 rows=6328206 width=0) (actual time=3184.053..3184.053 rows=6245831 loops=1)
              Index Cond: (username = 'testing'::text)
        ->  Bitmap Index Scan on index_events_fresh_x_event  (cost=0.00..124112.84 rows=6328206 width=0) (actual time=2478.919..2478.919 rows=6245841 loops=1)
              Index Cond: (x_event = 'play'::text)
Total runtime: 6148.313 ms

我有几个问题：

我是否更正日期索引中有554137行？有应该在那里不到50个日期。
我如何知道列出的三个使用哪个索引？
列出的总运行时间约为6秒，但是当我运行没有EXPLAIN ANALYZE的查询时，大约需要40秒。

Answer 1

首先，Scott Marlowe表示查询只需要6秒才能运行剩下的就是转移时间。没有解释分析似乎更慢，因为结果比解释分析输出的十行大得多，因此转移需要更长的时间。如果您打开查询记录并运行此查询，您可能会在日志中发现没有explain analyze的查询运行得更快（解释分析会减慢速度）。如果你正在使用的话，BTW pgadmin本身就很慢。

日期索引中的行数pg是对的。即使您只有50个不同的值，所有行也将在索引中。当然，btree部分本身只包含50个不同的值，但在每个叶子值下，它将包含该值的所有行的列表。当然有一个带有where子句的索引的特例，它只包含与where子句匹配的行，但是我不指望你正在使用它吗？

它使用的是解释分析输出中列出的所有索引。在这种情况下，它将每个索引转换为位图，该位图具有与该索引扫描的条件匹配的每一行的位集。然后可以非常快速地将这三个位图组合成包含组合标准结果的位图。

Answer 2

如果5.7秒不够好，您可以尝试多列索引：

create index index_name on events(user_name, date, x_event)

我首先放置了user_name，因为我猜它是具有最高cardinality的列。

Postgres查询需要比预期更长的时间，甚至是字段上的索引

2 个答案: