| From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp> | 
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Alternative variable length structure | 
| Date: | 2005-09-08 09:02:44 | 
| Message-ID: | 20050908174102.4C76.ITAGAKI.TAKAHIRO@lab.ntt.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Hi Hackers,
PostgreSQL can treat variable-length data flexibly, but therefore
it consumes more spaces if we store short data. Headers of
variable-length types use 4 bytes regardless of the data length.
My idea is to change the header itself to variable-length. 
In order to reduce the size of short data, I wrote a patch to encode
lengths into the first several bits of structure. Also, the alignments
of the types were changed to 'char' from 'int'.
I know my patch is still insufficient, for example, the types cannot
be TOASTed. But I guess this compression works well for short text.
I'll appreciate any comments.
thanks.
---- the result of patch ----
# create table txttbl (v1 text, v2 text, v3 text, v4 text);
# create table strtbl (v1 string, v2 string, v3 string, v4 string);
# insert into txttbl values('A', 'B', 'C', 'D');
# insert into strtbl values('A', 'B', 'C', 'D');
# select * from pgstattuple('txttbl');
-[ RECORD 1 ]------+------
table_len          | 8192
tuple_count        | 1
tuple_len          | 57    <-- 28 + (5+3) + (5+3) + (5+3) + (5)
...
# select * from pgstattuple('strtbl');
-[ RECORD 1 ]------+------
table_len          | 8192
tuple_count        | 1
tuple_len          | 36    <-- 28 + 2 + 2 + 2 + 2
...
---
ITAGAKI Takahiro
NTT Cyber Space Laboratories
| Attachment | Content-Type | Size | 
|---|---|---|
| varlena2.patch | application/octet-stream | 20.7 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Larry Rosenman | 2005-09-08 09:55:28 | Re: [COMMITTERS] pgsql: Update timezone data files to release 2005m of the zic database. | 
| Previous Message | Bruce Momjian | 2005-09-08 07:41:32 | Re: statement logging / extended query protocol issues |