Re: Something's been bugging me

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I'm not for this because it would complicate the already-too-complicated
>> inner-loop tests for deciding which form of datum you're looking at.
>>
>> The idea that I recall mentioning was to expend another byte in TOAST
>> pointers to make them self-identifying, ie, instead of 0x80 or 0x01
>> signaling something that *must* be a 17-byte toast pointer, that bit
>> pattern signals "something else" and the content of the next byte
>> lets you know what. So TOAST pointers would take 18 bytes instead of
>> 17, and there would be room for additions of other sorts of pointers.

> Hm, wouldn't that be just as expensive though?

No, I don't think so, because it'd be a second-level test that's only
hit after determining that you have a 1B_E kind of datum. Furthermore,
it'd only be hit if you were actually trying to determing the datum's
value, and not if (for instance) you only wanted to skip past it to the
next field.

> You would still have to look at
> the next byte and check it against various values to see what length to skip
> over. Hm, unless we put the length in the following byte.

Making the second byte contain the length would work well for the sorts
of cases I was envisioning, which was different sorts of fixed-size
pointer-ish objects. I suppose it would not scale well towards having a
different kind of inline compression method, but I don't see how your
proposal handles that either.

After a bit of reflection, I'd argue that variant inline compression
methods ought to be implemented within the 4B_C family of datum
representations. It looks to me like we have a couple of leftover bits
within that, because va_rawsize can't exceed 1G, and so there is room
to include two flag bits in it.

regards, tom lane