我正在寻找通过引用列类型和长度大小来获得预期的表大小.我正试图用pg_column_size它.
在测试函数时,我意识到这个函数似乎有些问题.
结果值pg_column_size(...)有时甚至小于octet_length(...)同一字符串上的返回值.
列中只有数字字符.
postgres=# \d+ t5
Table "public.t5"
Column | Type | Modifiers | Storage | Stats target | Description
--------+-------------------+-----------+----------+--------------+-------------
c1 | character varying | | extended | |
Has OIDs: no
postgres=# 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)
Run Code Online (Sandbox Code Playgroud)
这是虫子还是什么?是否有人使用某些公式从列类型和长度值计算预期的表大小?
Cra*_*ger 12
我要说的pg_column_size是报告TOASTed值的压缩大小,同时octet_length报告未压缩的大小.我没有通过检查函数源或定义来验证这一点,但这是有道理的,特别是因为数字串会很好地压缩.您正在使用EXTENDED存储,因此这些值适用于TOAST压缩.请参阅该TOAST文档.
至于计算预期的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)
Run Code Online (Sandbox Code Playgroud)
现在让我们将相同的查询输出存储到表中并获取存储行的大小:
regress=> CREATE TABLE blah AS SELECT repeat('1234567890',(2^n)::integer) AS data FROM generate_series(0,12) n;
SELECT 13
regress=> 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)
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
4617 次 |
| 最近记录: |