On 05/04/2011 07:05 PM, Tom Lane wrote:
> Alvaro Herrera<alvherre@commandprompt.com> writes:
>> Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
>>> Just out of curiosity, what actual functionality gain would ensue over
>>> just using text? It seems like doing anything useful with the audit
>>> table contents would still require casting the column to text, or the
>>> moral equivalent of that.
>> Storage efficiency. These people have really huge databases; small
>> changes in how tight things are packed makes a large difference for
>> them. (For example, we developed a type to store SHA-2 digests in a
>> more compact way than bytea mainly because of this reason. Also, at
>> some time they also wanted to apply compression to hstore keys and
>> values.)
> Hmm. The prototypical case for this would probably be a 4-byte int,
> which if you add an OID to it so you can resolve the type is going to
> take 8 bytes, plus you are going to need a length word because there is
> really no alternative to the "VARIANT" type being varlena overall, which
> makes it 9 bytes if you're lucky on alignment and up to 16 if you're
> not. That is not shorter than the average length of the text
> representation of an int. The numbers don't seem a lot better for
> 8-byte quantities like int8, float8, or timestamp. It might be
> marginally worthwhile for timestamp, but surely this is a huge amount of
> effort to substitute for thinking of a more compact text representation
> for timestamps.
>
> Pardon me for being unconvinced.
>
>
I'm far from convinced that storing deltas per column rather than per
record is a win anyway. I don't have hard numbers to hand, but my vague
recollection is that my tests showed it to be a design that used more space.
cheers
andrew
