"Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> #define VARDATA_4B(PTR) ((PTR)->va_4byte.va_data)
>> #define VARDATA_2B(PTR) ((PTR)->va_2byte.va_data)
>> #define VARDATA_1B(PTR) ((PTR)->va_1byte.va_data)
>
> I thought we had abandoned the 2-byte-header variant?
Hm, I don't remember anyone saying that. I had actually considered doing that
but concluded we couldn't or there wouldn't enough bits to indicate inline
compression. Now that I think about it we could just do it but I don't see
much of a case to do it.
> Maybe you need to start a separate thread about exactly which of the
> bit-level proposals you want to implement. There were quite a few tradeoffs
> discussed in the previous thread IIRC.
If I get the macro api right we can flip around what things indicate easily
enough.
Currently I'm just doing the second of the two you posted. That's the one with
the hard coded external toast datum size but able to handle 1-byte headers for
data up to 127 bytes long.
The other one you posted had one fewer cases for deform_tuple to consider but
only handled datums up to 63 bytes long in single byte headers. Both of those
were uniformly better than the previous alternatives.
>> Incidentally I profiled htonl against a right shift on my machine (an intel
>> 2Ghz core duo). htonl is four times slower but that's 3.2ns versus 0.8ns.
>
> Yeah, but what about machines that have stupider compilers, or maybe
> htonl isn't inlined at all? With a shift you pretty much know what
> you're getting, with htonl I'm not so sure.
I'm not against doing the shifting, I'm just going to get this working first
and then we can always add a separate set of equivalent macros for
little-endian machines.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com