"Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
