ale*_*pov 5 postgresql indexing
有一个 postgres 表,ENTRIES,有一个类型为 'made_at' 的列timestamp without time zone。
该表在该列和另一列(USER_ID,外键)上都有一个 btree 索引:
btree (user_id, date_trunc('day'::text, made_at))
Run Code Online (Sandbox Code Playgroud)
如您所见,日期在“天”处被截断。以这种方式构建的索引的总大小为 130 MB —— ENTRIES 表中有 4,000,000 行。
问题:如果我要注意达到秒的时间,我如何估计索引的大小?基本上,在秒而不是一天截断时间戳(我希望应该很容易做到)。
有趣的问题!根据我的调查,它们的大小相同。
我的直觉告诉我,你的两个索引的大小应该没有区别,因为 PostgreSQL 中的时间戳类型是固定大小(8 个字节),我认为 truncate 函数只是将适当数量的最低有效时间位清零,但我想我最好用一些事实来支持我的猜测。
我在 heroku PostgreSQL 上创建了一个免费的开发数据库,并生成了一个带有 4M 随机时间戳的表,截断为天和秒值,如下所示:
test_db=> SELECT * INTO ts_test FROM
(SELECT id,
ts,
date_trunc('day', ts) AS trunc_day,
date_trunc('second', ts) AS trunc_s
FROM (select generate_series(1, 4000000) AS id,
now() - '1 year'::interval * round(random() * 1000) AS ts) AS sub)
AS subq;
SELECT 4000000
test_db=> create index ix_day_trunc on ts_test (id, trunc_day);
CREATE INDEX
test_db=> create index ix_second_trunc on ts_test (id, trunc_s);
CREATE INDEX
test_db=> \d ts_test
Table "public.ts_test"
Column | Type | Modifiers
-----------+--------------------------+-----------
id | integer |
ts | timestamp with time zone |
trunc_day | timestamp with time zone |
trunc_s | timestamp with time zone |
Indexes:
"ix_day_trunc" btree (id, trunc_day)
"ix_second_trunc" btree (id, trunc_s)
test_db=> SELECT pg_size_pretty(pg_relation_size('ix_day_trunc'));
pg_size_pretty
----------------
120 MB
(1 row)
test_db=> SELECT pg_size_pretty(pg_relation_size('ix_second_trunc'));
pg_size_pretty
----------------
120 MB
(1 row)
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
2753 次 |
| 最近记录: |