Jim C. Nasby wrote:
> On Wed, Jun 14, 2006 at 02:53:10PM -0400, Bruce Momjian wrote:
> >
> > I assume the conclusion from this email thread is that though the idea
> > is interesting, the complexity added would not be worth the saving of a
> > few bytes.
>
> Anyone do any testing?
>
> I'm also wondering if this would be useful to allow fields larger than
> 1G.
The submitter showed the pathological case where a single char was
stored in a text field, and showed the reduced size (below). There were
no performance numbers given. It seems like an edge case, especially
since we have a "char" type that is a single byte.
---------------------------------------------------------------------------
> >
> > ITAGAKI Takahiro wrote:
> > > 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, skipping... ]
> >
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 6: explain analyze is your friend
> >
> > --
> > Bruce Momjian http://candle.pha.pa.us
> > EnterpriseDB http://www.enterprisedb.com
> >
> > + If your life is a hard drive, Christ can be your backup. +
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
> --
> Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
> Pervasive Software http://pervasive.com work: 512-231-6117
> vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
>
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
