【问题标题】:Checking if a postgres index is up to date?检查 postgres 索引是否是最新的?
【发布时间】:2018-03-16 22:51:37
【问题描述】:

给定一个每月添加大约 500 万条记录的表,这个简单的查询从第一次执行到第二次执行的运行时间大不相同:

select count(*) from my_table where recorded_at > '2018-01-24 23:59:59'
  • 第一次执行:count = 8,756,237 执行时间 = ~5 分钟
  • 第二 执行:count = 8,756,237 执行时间 = ~3 秒

recorded_at 字段上有一个索引。

CREATE INDEX my_table__recorded_at ON my_table(recorded_at);

执行时间的这种差异是否表明索引没有正确更新?

其他日期也一样:

select count(*) from my_table where recorded_at > '2018-02-07 23:59:59'
  • 第一次执行:计数 = 6,487,274 次执行时间 = ~4 分钟
  • 第二次执行:计数 = 6,487,274 次执行时间 = ~3 秒

这是在带有 r4.xlarge 实例的 AWS Aurora postgres 上运行

【问题讨论】:

  • 您可以检查索引是否与EXPLAIN SELECT count(*) FROM my_table WHERE recorded_at > '2018-02-07 23:59:59'; 一起使用。也就是说,我强烈怀疑您看到的是缓存表和/或索引的效果。第一次运行时,它会读取所有内容并缓存内容。第二次,它只需要去缓存。最后,除非 Aurora 与 postgres 完全不同,否则索引总是会更新。
  • 这是一个相当典型的情况,即第一次执行查询比下一次执行慢得多。这是由于 Postgres 和/或文件系统缓存。在此基础上,不太可能相信数据以任何方式损坏或过时。
  • 是的,您的索引是最新的。请下一个问题!

标签: postgresql performance indexing


【解决方案1】:

索引在每个 DML 之后都是最新的。

你可以使用:

EXPLAIN (analyze, verbose, buffers)
SELECT COUNT(*)
FROM my_table
WHERE recorded_at > '2018-01-24 23:59:59'

获取有关缓存命中、I/O 时序的更多信息。

如果您认为您的索引已损坏,还有REINDEX 命令。

也许pg_prewarm 模块会很有趣。

【讨论】:

  • Hmmm....索引可能是正确的,但在许多 DBMS 上批量插入后它们可能会不平衡。
猜你喜欢
  • 1970-01-01
  • 2014-05-21
  • 1970-01-01
  • 2021-07-22
  • 2013-08-23
  • 1970-01-01
  • 2021-09-23
  • 2021-12-29
  • 2012-11-30
相关资源
最近更新 更多