PostgreSQL 数据库维护

  • 时间:
  • 浏览:0
  • 来源:uu快3开奖_uu快3娱乐_输钱

(1 row)

#      着实降低了,说明它们占用的物理空间可能性缩小了。

VACUUM

postgres=# SELECT relname,relfilenode, relpages FROM pg_class WHERE relname = 'testtable' or relname = 'testtable_idx';

#12. 再重新批量插入两次,随后在分析该表以更新其统计信息。

testtable        |       172001   |      157

#14. 都都要看到索引的页面数量着实这样 继续增加。

CREATE TABLE

CREATE INDEX

#5. 确认四次批量插入都成功。

relname      | relfilenode    | relpages

#4. 批量插入数据到测试表(执行四次)

#2. 为测试表创建索引。

END;

postgres=# CREATE OR REPLACE FUNCTION test_insert() returns integer AS $$

ANALYZE

RETURN 0;

  2. 查看指定数据表的索引名称和索引占用的磁盘页面数量。

(1 row)

postgres=# VACUUM ANALYZE testtable;

DELETE 20003

#15. 重新批量删除数据。

FOR i IN min..max LOOP

  1. 查看数据表所占用的磁盘页面数量。

#9. 执行vacuum和analyze,以便更新系统表,一块儿为该表和索引记录高水标记。

END LOOP;

#11. 查看测试表和索引在删除后,再通过VACUUM ANALYZE更新系统统计信息后的结果(保持不变)。

postgres=# SELECT relname,relfilenode, relpages FROM pg_class WHERE relname = 'testtable' or relname = 'testtable_idx';

  在PostgreSQL中,为数据更新频繁的数据表定期重建索引(REINDEX INDEX)是非常有必要的。对于B-Tree索引,只哪些地方地方地方可能性详细清空的索引页才会得到重复使用,对于哪些地方地方仅部分空间可用的索引页将不不得到重用,可能性有另另一个 页面中大多数索引键值都被删除,只留下很少的一部分,这样 该页将不不被释放并重用。在你你這個 极端的具体情况下,可能性每个索引页面的利用率极低,一旦数据量显著增加,可能性意味索引文件变得极为庞大,不仅降低了查询数率,否则还居于整个磁盘空间被详细填满的危险。

postgres=# SELECT relname,relfilenode, relpages FROM pg_class WHERE relname = 'testtable' or relname = 'testtable_idx';

relname      | relfilenode     | relpages

---------------+-------------+----------

postgres=# ANALYZE testtable;

(2 rows)

testtable_idx  |       172005   |       68

INSERT INTO testtable VALUES(i);

testtable_idx  |       172004   |       90

count

  对于重建后的索引还居于另外有另另一个 性能上的优势,可能性在新建立的索引上,逻辑上相互连接的页面在物理上往往也是连在一块儿的,另有另另一个 都都要提高磁盘页面被连续读取的几率,从而提高整个操作的IO数率。见如下示例:

testtable_idx  |       172004   |      173

---------------+-------------+----------

$$ LANGUAGE plpgsql;

DELETE 19996

(2 rows)

#16. 从后边的查询都都要看出,在执行VACUUM FULL命令随后,测试表和索引所占用的页面数量

---------------+-------------+----------

relname       | relfilenode    | relpages

testtable        |       172001   |      157

(1 row)

ANALYZE

#10. 这里都要额外说明的是,后边删除的数据均居于数据表的前部,可能性删除的是末尾部分,

postgres=# ANALYZE testtable;

test_insert

postgres=# CREATE TABLE testtable (i integer);

CREATE FUNCTION

postgres=# DELETE FROM testtable WHERE i < 20000;

postgres=# SELECT COUNT(*) FROM testtable;

20004

ANALYZE

test_insert

#13. 此时都都要看到数据表中的页面数量仍然为随后的高水标记数量,索引页面数量的增加

max := min + 20000;

min integer;

BEGIN

relname      | relfilenode     | relpages

(2 rows)

postgres=# ANALYZE testtable;

test_insert

max integer;

#6. 分析测试表,以便有关该表的统计信息被更新到PostgreSQL的系统表。

ANALYZE

testtable        |       172002   |      118

postgres=# SELECT relname,relfilenode, relpages FROM pg_class WHERE relname = 'testtable' or relname = 'testtable_idx';

#7. 查看测试表和索引当前占用的页面数量(通常每个页面为8k)。

testtable_idx  |       172004   |      173

(2 rows)

DECLARE

#8. 批量删除数据。

-------------

relname       | relfilenode    | relpages

-------------

postgres=# SELECT test_insert();

postgres=# DELETE FROM testtable WHERE i < 20000;

postgres=# SELECT test_insert(); --执行两次。

#      如where i > 20000,这样 在执行VACUUM ANALYZE的随后,数据表可能性被物理的缩小。

-------------

testtable        |       172001   |      157

#3. 创建批量插入测试数据的函数。

---------------+-------------+----------

testtable_idx  |       172004   |       90

postgres=# SELECT test_insert();

#1. 创建测试数据表。

testtable        |       172001   |      157

-------

#      是和其实物实现法律方式 有关,否则在后边的插入中,索引所占的页面数量就不不继续增加。

postgres=# VACUUM FULL testtable;

---------------+-------------+----------

postgres=# CREATE INDEX testtable_idx ON testtable(i);

postgres=# SELECT relname,relfilenode, relpages FROM pg_class WHERE relname = 'testtable' or relname = 'testtable_idx';

(1 row)

SELECT COUNT(*) INTO min from testtable;