博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
PostgresSQL-重建索引
阅读量:6568 次
发布时间:2019-06-24

本文共 692 字,大约阅读时间需要 2 分钟。

hot3.png

有时候我们值得用  命令周期的重建索引。

在 PostgreSQL 版本 7.4 之前,我们经常有必要避免"索引膨胀", 因为缺乏在 B-tree 索引内部的空间恢复机制。一个情况是就是索引健字的范围随着时间而变化 — 比如,一个在某个表的时间戳上的索引,随着时间的推移,旧的记录会最终被删除 — 就会导致膨胀,因为那些用于不再使用的键字范围的索引页面不回得到重复使用。 随着时间的推移,索引的尺寸可能会变得比里面的有用的数据大得多。

从 PostgreSQL 7.4 开始,那些已经完全清空的索引页会得到重复使用。 不过这样仍然会有不充分使用空间的可能:如果一个页面中大多数索引键字被删除,只留下很少的部分呢, 那么该页仍然将被分配。所以,如果使用模式是这样的:每个范围里除了少数键字之外,其他大部分键字最终都被删除; 那么这样也会导致空间的低效使用。膨胀的可能性不是无穷的 — 最差的情况是每个页面至少还有一个键字 — 但是对这样的使用模式,我们可能仍然值得安排周期性的重新索引

对于非 B-tree 索引的膨胀可能还没有很好地定量分析。 在使用非 B-tree 索引的时候保持对索引的物理尺寸的监控是个很好的主意。

还有,对于 B-tree 索引,一个新建立的索引从某种意义上比更新了多次的访问起来要快, 因为在新建立的索引上,逻辑上连接的页面通常物理上也连接在一起。 (这样的考虑目前并不适用于非 B-tree 索引。)仅仅从提高访问速度角度出发, 可能我们也值得周期性的重建索引。

转载于:https://my.oschina.net/hrbeu05/blog/373793

你可能感兴趣的文章
【转】持久化消息队列之MEMCACHEQ
查看>>
Dom4j学习笔记
查看>>
C语言 HTTP上传文件-利用libcurl库上传文件
查看>>
[MEAN Stack] First API -- 7. Using Route Files to Structure Server Side API
查看>>
调试逆向分为动态分析技术和静态分析技术(转)
查看>>
Android webview使用详解
查看>>
业务对象和BAPI
查看>>
程序源系统与当前系统不一致:Carry out repairs in non-original systems only if urgent
查看>>
微软职位内部推荐-Senior Software Engineer
查看>>
程序中的魔鬼数字
查看>>
SVN高速新手教程
查看>>
session cookie
查看>>
ZBar之ZBarReaderViewController
查看>>
Nuget~管理自己的包包~丢了的包包快速恢复
查看>>
$.extend({},defaults, options) --(初体验三)
查看>>
jQuery hover() 方法
查看>>
android 一步一步教你集成tinker(热修复)
查看>>
到底有多少内存
查看>>
centos7.3 安装ovirt-engine4.0 版本
查看>>
Jenkins+git+tomcat 自动化持续部署
查看>>