postgresql - PostgreSQL 表的大小错误(?)

标签 postgresql storage vacuum

我有一个包含列和约束的表:

height smallint,
length smallint,
diameter smallint,
volume integer,
idsensorfragments integer,
CONSTRAINT sensorstats_idsensorfragments_fkey FOREIGN KEY (idsensorfragments)
  REFERENCES sensorfragments (idsensorfragments) MATCH SIMPLE
  ON UPDATE CASCADE ON DELETE CASCADE

(无主键)。目前有 28 978 112 条记录,但我认为表的大小太大了。

查询结果:

select pg_size_pretty(pg_total_relation_size('sensorstats')), pg_size_pretty(pg_relation_size('sensorstats'))

是:

"1849 MB";"1226 MB"

idsensorfragments 列只有一个索引。使用简单的数学运算,您可以看到一条记录需要 ~66,7 B (?!?!)。谁能解释一下这个数字是从哪里来的?

5 列 = 2 + 2 + 2 + 4 + 4 = 14 字节。我只有一个索引,没有主键。每条记录额外的 50B 从何而来?

附言对表进行清理、分析和重新索引。

最佳答案

你应该看看如何Database Physical Storage有条理,尤其是在 Page Layout 上.

PostgreSQL 为每个元组(行)和每个页面保留了一堆额外的字段。元组保存在页面中,因为页面是数据库操作的项目,通常大小为 8192 字节。所以额外的空间使用来自:

  • 页眉,24字节;
  • 元组头,27字节;
  • “隐形”元组版本;
  • 根据Storage Parameters保留的可用空间表;
  • NULL 指标数组;
  • (可能漏掉了更多内容)。

物理存储的布局在主要版本之间发生变化,这就是您必须执行完整转储/恢复的原因。在最近的版本中 pg_upgrade在这个过程中有很大的帮助。

关于postgresql - PostgreSQL 表的大小错误(?),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11306348/

相关文章:

postgresql - Postgres 描述聚合函数为用户定义的类型返回类型修改值 -1

c++ - 二叉存储树 fstream 出错

storage - 阻止 rsync 删除未完成的源文件

amazon-redshift - Amazon Redshift VACUUM 是按架构还是按数据库运行?

postgresql - 序列不存在时存在 - Postgres/Spring Boot

ruby-on-rails - Heroku 运行 rake db :migrate error rake command not found

Postgresql - 从 500Gb 数据库/自动真空中大量删除?

optimization - 如何自动确定哪些表需要在 postgresql 中进行真空/重建索引

database - 为什么 Postgres 不为我的查询使用更好的索引?

java - 如何存储坐标以像六边形结构一样工作?