From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)skype(dot)net> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reducing data type space usage |
Date: | 2006-09-18 14:05:14 |
Message-ID: | 27210.1158588314@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)skype(dot)net> writes:
> would adding this -
> first byte 0xxxxxxx ---- field length 1 byte, exactly that value
> first byte 10xxxxxx ---- 0xxxxxx data bytes follow
> first byte 110xxxxx -- xxxxx xxxxxxxx data bytes to follow
> first byte 111xxxxx -- xxxxx xxxxxxxx xxxxxxxx xxxxxxxx bytes t.flw
> be too expensive ?
What's the point? Unless there's provision for TOAST, you can't put
arbitrarily long strings on disk anyway, so I don't see what this
datatype can do that is much better than the simpler version. If you
try to fit TOAST in, then you are back to exactly the var-length-varlena
proposals upthread.
To me the only really compelling argument for worrying about the size
of the header is for fields that are certain to be short, such as
poor-mans-enumerated-type strings, part numbers, etc. The
zero-or-one-byte header approach seems to handle that use-case just
fine. I think more complicated approaches are going to add lots of
code and cycles for only very marginal gains.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-18 14:10:32 | Re: 8.2 beta blockers |
Previous Message | Gevik Babakhani | 2006-09-18 14:02:56 | OID conflicts |