| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| 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 19:45:58 |
| Message-ID: | 20210804194558.ezcniy7pghyywxh5@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2021-08-04 15:37:36 -0400, Robert Haas wrote:
> On Wed, Aug 4, 2021 at 3:01 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > Extending that to arbitrary lengths obviously at some point makes the encoding
> > in unary wasteful, and the benefit of few branches vanishes. So what I was
> > thinking is that for variable length pieces of data that are not limited to 8
> > bytes, we could replace the '8 0 bits' special case with a new special case:
> > The length in bytes follows as a max-8-byte varint.
>
> But what if I have a machine with more than 16 exabytes of RAM and I
> want to use all of its memory to store one really big integer?
Then the embedded 8 byte length value would just have to do the same thing
recursively to store that huge length header :)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-08-04 20:34:52 | Re: straightening out backend process startup |
| Previous Message | Andres Freund | 2021-08-04 19:44:44 | Re: RFC: Improve CPU cache locality of syscache searches |