最近开发部门的测试提出一个问题,在我们某一个项目的postgresql V12的服务器上某个表在查询的时候1000行数据竟然跑出了 27秒的"好成绩". 我大PG 的性能这么差,这不能呀....从上图看的确是如此,并且pg_admin还因为查询时过载,重新启动了服务
既然这个事情是既定的事实,那么我们先来看看这个表的表结构是什么....Extended 允许压缩和跨行存储,这个是每个列最常见的存储的模式,首先要压缩然后在toast存储
EXTERNAL 这个方式和上的方式的区别就是压缩,这样的存储是不会对数据进行压缩处理的,直接而这样的方式对于...text和bytea存储是可以相对于上的存储方式要快速的....这个就是我们toast表中存储的数据
通过上面的分析,在实际生产中我们再次确认TOAST 功能的强大, 在实际应用中可以存储巨量的数据,但付出的代价是提取速度的问题,但如果27秒能提取 215MB 的数据量