From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: extensible external toast tuple support & snappy prototype |
Date: | 2013-06-07 16:16:48 |
Message-ID: | 20130607161648.GB7200@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> Currently on a little endian system the pglz header contains the length
> in the first four bytes as:
> [dddddddd][dddddddd][dddddddd][xxdddddd]
> Where dd are valid length bits for pglz and xx are the two bits which
> are always zero since we only ever store up to 1GB. We can redefine 'xx'
> to mean whatever we want but we cannot change it's place.
I'm not thrilled with the idea of using those 2 bits from the length
integer. I understand the point of it and that we'd be able to have
binary compatibility from it but is it necessary to track at the
per-tuple level..? What about possibly supporting >1GB objects at some
point (yes, I know there's a lot of other issues there, but still).
We've also got complexity around the size of the length integer already.
Anyway, just not 100% sure that we really want to use these bits for
this.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2013-06-07 16:18:00 | Re: create a git symbolic-ref for REL9_3_STABLE |
Previous Message | Hannu Krosing | 2013-06-07 16:12:56 | Re: extensible external toast tuple support & snappy prototype |