在测试函数时,我意识到这个函数似乎有些问题.
pg_column_size(…)的结果值有时甚至小于同一字符串上octet_length(…)的返回值.
列中只有数字字符.
postgres=# \d+ t5 table "public.t5" Column | Type | ModifIErs | Storage | Stats target | Description --------+-------------------+-----------+----------+--------------+------------- c1 | character varying | | extended | | Has OIDs: nopostgres=# select pg_column_size(c1),octet_length(c1) as octet from t5; pg_column_size | octet ----------------+------- 2 | 1 704 | 700 101 | 7000 903 | 77000(4 rows)
这是虫子还是什么?是否有人使用某些公式从列类型和长度值计算预期的表大小?
我会说pg_column_size报告TOASTed值的压缩大小,而octet_length报告未压缩的大小.我没有通过检查函数源或定义来验证这一点,但它是有意义的,特别是因为数字串将压缩得很好.您正在使用EXTENDED存储,因此这些值适用于TOAST压缩.见 theTOAST
documentation. 至于计算预期的DB大小,这是一个全新的问题.从下面的演示中可以看出,它取决于你的字符串是如何可压缩的.
这是一个演示,展示了octet_length如何比pg_column_size更大,展示了TOAST开始的地方.首先,让我们在查询输出中得到结果,其中没有TOAST发挥作用:
regress=> SELECT octet_length(repeat('1234567890',(2^n)::integer)),pg_column_size(repeat('1234567890',(2^n)::integer)) FROM generate_serIEs(0,12) n; octet_length | pg_column_size --------------+---------------- 10 | 14 20 | 24 40 | 44 80 | 84 160 | 164 320 | 324 640 | 644 1280 | 1284 2560 | 2564 5120 | 5124 10240 | 10244 20480 | 20484 40960 | 40964(13 rows)
现在让我们将相同的查询输出存储到表中并获取存储行的大小:
regress=> CREATE table blah AS SELECT repeat('1234567890',(2^n)::integer) AS data FROM generate_serIEs(0,12) n;SELECT 13regress=> SELECT octet_length(data),pg_column_size(data) FROM blah; octet_length | pg_column_size --------------+---------------- 10 | 11 20 | 21 40 | 41 80 | 81 160 | 164 320 | 324 640 | 644 1280 | 1284 2560 | 51 5120 | 79 10240 | 138 20480 | 254 40960 | 488(13 rows)总结
以上是内存溢出为你收集整理的postgresql – pg_column_size如何小于octet_length?全部内容,希望文章能够帮你解决postgresql – pg_column_size如何小于octet_length?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)