Re: A varint implementation for PG?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
Subject: Re: A varint implementation for PG?
Date: 2021-08-04 13:31:25
Message-ID: CA+TgmobDC1wSTbttmFLMgcT7C0HpsU8M6svNytQcwkuc6Z29Cg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 3, 2021 at 3:32 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-08-04 13:43:13 Re: Parallel scan with SubTransGetTopmostTransaction assert coredump
Previous Message Andrew Dunstan 2021-08-04 13:26:26 Release 13.1 of the PostgreSQL BuildFarm client