Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match