Excerpts from Tom Lane's message of mié may 04 20:05:54 -0300 2011:
> 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.
Hmm, I was hoping that we could skip making it varlena at least in some
cases ... perhaps that's hopeless, in which case we'll have to reassess
the whole idea. Still there's the new functionality argument, though.
As a followup idea there exists the desire to store records as records
and not text representation of same (given differing record types, of
course), for which it'd be more worthwhile.
> 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.
Surely if it's just for timestamps it'd be a waste of time.
> Pardon me for being unconvinced.
:-)
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
