digoal
2021-09-02
PostgreSQL , 全局临时表
1、产品的问题点
- PG 没有全局临时表
2、问题点背后涉及的技术原理
- PG 的临时表是使用时创建, 结构定义在1个会话内有效.
- 每次创建临时表时, 需要在pg_class, pg_stats, pg_attribute等元数据中插入临时表的对象数据、统计信息数据、字段定义数据等. 在会话结束是再从这些元数据表中删除.
3、这个问题将影响哪些行业以及业务场景
- 频繁使用临时表的业务. 例如将业务逻辑放入数据库存储过程中, 使用临时表来存放一些中间计算结果.
4、会导致什么问题?
- 元数据表、元数据表对应的索引膨胀.
- 使用不便, 每次使用临时表都需要重新创建.
5、业务上应该如何避免这个坑
- 目前带来的膨胀副作用基本无解.
- 可以使用一些方法自动创建临时表, 而不需要每次创建
- 使用array或者json类型来存储中间结果, 代替temp table.
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 外部依赖导致了管理成本的增加
- array, json的单值上限是1G, 有使用局限性. 而且操作起来不如临时表便利.
7、数据库未来产品迭代如何修复这个坑
- 有一些patch, 希望内核层支持全局临时表
- 在一些基于PG的数据数据库中有看到全局临时表的功能, 例如PolarDB. 可参考阅读: 《一起学PolarDB - 第9期 - 为什么经常使用临时表时建议使用全局临时表?》
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
