Re: VARIANT / ANYTYPE datatype

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: VARIANT / ANYTYPE datatype
Дата
Msg-id 19149.1304550354@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: VARIANT / ANYTYPE datatype  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: VARIANT / ANYTYPE datatype
Re: VARIANT / ANYTYPE datatype
Список pgsql-hackers
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.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: VARIANT / ANYTYPE datatype
Следующее
От: "Johann 'Myrkraverk' Oskarsson"
Дата:
Сообщение: Re: DLL export with mingw-w64: currently a no-op