时间戳相对于当前时间的部分索引

Cha*_*ata 7 postgresql indexing timestamp query-optimization partial-index

我有一个查询,通过比较五个月前的插入时间戳来过滤行。

该字段不会更新,如果有帮助的话我们可能会认为它是不可变的。

CREATE TABLE events (
    id serial PRIMARY KEY,
    inserted_at timestamp without time zone DEFAULT now() NOT NULL
);

SELECT *
FROM events e
WHERE e.inserted_at >= (now() - '5 minutes'::interval);
Run Code Online (Sandbox Code Playgroud)

EXPLAIN ANALYZE VERBOSE

Seq Scan on public.events e  (cost=0.00..459.00 rows=57 width=12) (actual time=0.738..33.127 rows=56 loops=1)
    Output: id, inserted_at
    Filter: (e.inserted_at >= (now() - '5 minutes'::interval))
    Rows Removed by Filter: 19944
Planning time: 0.156 ms
Execution time: 33.180 ms
Run Code Online (Sandbox Code Playgroud)

看来 PostgreSQL 在现场执行序列扫描,这会增加成本。

我是否有机会创建 B 树部分索引或其他任何内容来优化该查询?

Vao*_*sun 4

最后 5 分钟的部分索引每隔一段时间就需要重建。您可以与 cron 同时构建它(因为您的关系正在大量使用),删除旧索引。当然,这种方法可以让您更快地选择最后插入的数据,但请考虑这样一个事实:至少每 5 分钟您必须重新扫描表以构建短的部分索引。

解决方法是数学 - 您可以分阶段拆分索引构建(作为函数):

select now()- inserted_at >= '5 minutes'::interval
from events 
where id > (currval('events_id_seq') - 5*(1000000/30))
Run Code Online (Sandbox Code Playgroud)

即获取低于最后 id 值减去最近 5 分钟插入的近似值的 id。

如果结果为真,则使用相同的数学在动态查询中建立索引,如果不是,则扩大步骤。

这样你只扫描 PK 来在时间戳上建立索引 - 会便宜得多。

另一点 - 如果你应用这样的计算,你可能根本不需要部分索引?..