Postgresql 上时间戳字段的正确索引答案

【问题标题】：Right index for timestamp field on PostgresqlPostgresql 上时间戳字段的正确索引
【发布时间】：2015-03-01 18:02:57
【问题描述】：

这是桌子

CREATE TABLE material
(
  mid bigserial NOT NULL,
...
  active_from timestamp without time zone,
....
  CONSTRAINT material_pkey PRIMARY KEY (mid),
)

CREATE INDEX i_test_t_year
  ON material
  USING btree
  (date_part('year'::text, active_from));

如果我按中场排序

select mid from material order by mid desc
"Index Only Scan Backward using material_pkey on material  (cost=0.29..3573.20 rows=100927 width=8)"

但如果我使用 active_from 进行排序

select * from material order by active_from desc
"Sort  (cost=12067.29..12319.61 rows=100927 width=16)"
"  Sort Key: active_from"
"  ->  Seq Scan on material  (cost=0.00..1953.27 rows=100927 width=16)"

也许 active_from 的索引错误？如何以更低的成本制作合适的产品

【问题讨论】：

最佳索引取决于整个设置和最常见/最重要的查询。我严重怀疑 select * from material order by active_from desc 是您要使用的实际查询。没有WHERE 条件？对您的 Postgres 版本保密尤其无益。

标签： sql postgresql indexing

【解决方案1】：

date_part('year'::text, active_from) 上的索引不能用于active_from 排序；你知道按该函数排序，然后按 active_from 排序与简单地按 active_from 排序的顺序相同，但 postgresql 没有。如果您创建以下索引：

CREATE INDEX i_test_t_year ON material (active_from);

那么 postgresql 将能够使用它来回答查询：

Index Scan Backward using i_test_t_year on material  (cost=0.15..74.70 rows=1770 width=16)

但是，请记住，如果 postgresql 认为它比执行顺序扫描然后排序更快，它只会使用索引，因此创建正确的索引并不能保证它将用于此查询。

【讨论】：

好的，这是我的作品“使用 i_test_t_year 对材料进行索引向后扫描（成本=0.29..3579.79 行=100927 宽度=16）”
这很奇怪！如果我制作索引 - CREATE INDEX i_test_t_year ON material (active_from DESC LAST);它没有在查询中使用。为什么用顺序查询不使用顺序索引

【解决方案2】：

你需要完全理解一个索引，我相信这会回答你的问题。

索引实际上是存储在表旁边的自己的内存中的查找。您实际上是查看索引，然后它指向要获取的行。

如果您查看索引，您存储的是从“active_from”列中提取的“年份”的 TEXT 值。

因此，如果您要查看索引，它将看起来像一堆条目：

它们存储为 TEXT 值，而不是时间戳。

在您的查询中，您将 DESC 作为时间戳值排序。

所以它只是与您存储的索引不匹配。

如果您在查询中将 ORDER BY 设置为“order by date_part('year'::text,active_from)”，那么它将调用您放在那里的索引。

所以我建议你只在“active_from”上添加索引，根本不解析日期。

【讨论】：