Re: A varint implementation for PG?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: A varint implementation for PG?
Дата
Msg-id CA+TgmobDC1wSTbttmFLMgcT7C0HpsU8M6svNytQcwkuc6Z29Cg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: A varint implementation for PG?  (Andres Freund <andres@anarazel.de>)
Ответы Re: A varint implementation for PG?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Tue, Aug 3, 2021 at 3:32 PM Andres Freund <andres@anarazel.de> wrote:
> I am now wondering if what we're talking about here would best be thought of
> not as a variable width integer type, but a variable-width encoding for all
> pass-by-value types.
>
> Leaving on-disk compatibility aside (:)), ISTM that we by default could use
> the following heuristic to decide how to encode pass-by-value types: If it's a
> leading fixed-width NOT NULL type, store it in fixed-length
> encoding. Otherwise use a variable-length encoding.

This is pretty integer-centric, though. If your pass-by-value type is
storing timestamps, for example, they're not likely to be especially
close to zero. Since a 64-bit address is pretty big, perhaps they're
still close enough to zero that this will work out to a win, but I
don't know, that seems a bit cheesy. I grant that it could work out to
a win -- pass-by-value data types whose distribution is very different
from what's typical for integers, or for that matter columns full of
integers that all happen to be toward the extreme values the data type
can store, are probably not that common. I just don't really like
making such assumptions on a system-wide basis (as opposed to a
per-datatype basis where it's easier to reason about the
consequences).

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Release 13.1 of the PostgreSQL BuildFarm client
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Parallel scan with SubTransGetTopmostTransaction assert coredump