sql – 作为PK的顺序索引的填充因子
是的,再次填充因子.我花了很多时间阅读,我无法确定每个案例哪个是更好的填充因子.问题是我不明白碎片何时以及如何制作.我正在将数据库从MS SQL Server迁移到PostgreSQL 9.2. 情况1)连续(连续)PK中10-50次插入/分钟,每小时20-50次读取. CREATE TABLE dev_transactions ( transaction_id serial NOT NULL,transaction_type smallint NOT NULL,moment timestamp without time zone NOT NULL,gateway integer NOT NULL,device integer NOT NULL,controler smallint NOT NULL,token integer,et_mode character(1),status smallint NOT NULL,CONSTRAINT pk_dev_transactions PRIMARY KEY (transaction_id) ) WITH ( OIDS=FALSE ); 情况2)PK顺序的类似结构索引将以每个2个月~50,000个寄存器的块(一次)写入,读数为10-50 /分钟. 50%的填充因子意味着在每个插入中将生成一个新页面并将50%的现有记录传输到新的生成页面? 50%的填充因子意味着在创建新页面时,将保留复制的记录以避免在两者之间插入? 只有在没有空间分配记录时才会生成新页面? 你可以看到我很困惑;我会很感激它的一些帮助 – 也许是阅读有关PostgreSQL和索引填充因子的好链接. 解决方法FILLFACTOR
只使用INSERT和SELECT,你应该在任何地方使用100的FILLFACTOR. 如果您不打算使用UPDATE“摆动”,那么每个内存块的摆动空间是没有意义的. FILLFACTOR背后的机制非常简单. INSERT仅填充每个数据页(通常为8 kb块),最多为FILLFACTOR设置声明的百分比.此外,无论何时在桌面上运行VACUUM FULL或CLUSTER,都会重新建立每个块的相同摆动空间.理想情况下,这允许UPDATE在同一数据页中存储新行版本,这可以在处理大量UPDATE时提供显着的性能提升.与H.O.T.结合使用也是有益的.更新: > Redundant data in update statements 如果没有更新,请不要为此浪费空间并设置FILLFACTOR = 100. 基本信息来源: 其他优化 但你可以做别的事 – 因为你似乎是一个优化的傻瓜… (编辑:淮北站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |