Bro*_*oks 10 postgresql index restore postgresql-9.4
我看到其他问题的答案是否定的(即索引不会随标准转移pg_restore
)。但是,它看起来像在我最近的转储/恢复中一样,我不确定它是否真的转移了。
我将我的数据库从 PostgreSQL 9.3 迁移到 9.4.5 并使用转储/恢复来这样做。
下面是使用的命令:
sudo -u postgres pg_dump -h localhost -p 5432 -d nominatim -F d -f dump/postgres/backup -j 20
sudo -u postgres pg_restore --create --dbname=nominatim --exit-on-error -h localhost -p 5432 -F d -j 7 dump/postgres/backup
Run Code Online (Sandbox Code Playgroud)
转储和恢复成功(没有错误)。
我在进行恢复时将 autovacuum 设置为关闭,因此我analyze
从 psql 中运行(无参数)并连接到已恢复的数据库。
我注意到的第一件事是,在 9.3 下,数据目录占用了大约 860GB,而在 9.4 下,它占用了大约 680GB。9.4 是不是更高效?
我注意到的第二件事是我看到了数据库中的索引:
nominatim=# \d country_name
Table "public.country_name"
Column | Type | Modifiers
-------------------------------+---------------------------------
country_code | character varying(2) |
name | hstore |
country_default_language_code | character varying(2) |
partition | integer |
Indexes:
"idx_country_name_country_code" btree (country_code)
nominatim=# \d idx_country_name_country_code
Index "public.idx_country_name_country_code"
Column | Type | Definition
--------------+----------------------+--------------
country_code | character varying(2) | country_code
btree, for table "public.country_name"
nominatim=# select * from pg_indexes where tablename = 'country_name';
schemaname | tablename | indexname | tablespace | indexdef
------------+--------------+-------------------------------+------------+---------------------------------------------------------------------------------------
public | country_name | idx_country_name_country_code | | CREATE INDEX idx_country_name_country_code ON country_name USING btree (country_code)
(1 row)
Run Code Online (Sandbox Code Playgroud)
我是否仍然需要重新索引或者我的索引以某种方式或其他方式完成了还是我所看到的只是索引定义?任何关于更好地管理转储/恢复、检查我的索引等的进一步提示肯定会受到赞赏。
Erw*_*ter 19
索引是否通过 pg_restore 传输?
我看到其他问题的答案是否定的(即索引不会通过标准 pg_restore 转移)
这似乎是个误会。索引本身(包含所有数据)不在转储中。只是重新创建它的命令。因此,索引被“转移”,但实际上,它们是在原始状态下重新创建的,没有任何膨胀或死元组
我还需要重新索引吗?
不会。恢复后,您的所有索引都处于完美状态。不需要REINDEX
。ANALYZE
但是,正如“恢复转储”一章中的手册中所建议的那样,这是有道理的:
恢复备份后,明智的做法是
ANALYZE
在每个数据库上运行,以便查询优化器具有有用的统计信息;
最后:
9.4 是不是更高效?
不,一般不会。嗯,GIN 索引的大小已经大大减少了。但是您看到的很可能是从所有表和索引(包括系统表)中删除膨胀的效果。
归档时间: |
|
查看次数: |
10202 次 |
最近记录: |