"Tom Lane" <[EMAIL PROTECTED]> writes: > I'd be inclined to make the second byte be the length and have > VARSIZE_1B_E depend on that --- any objection?
On one hand it offends me since it's hard coding an assumption that the size of a pointer decides what it contains and vice versa. There's nothing saying we won't have two possible special meanings for a one-byte datum. And it forecloses any possibility of having a type whose size is at all variable. I like your idea of using the 4-byte header for variable sized structures, but what about structures whose size depends on an architecture detail. We might one day have a pointer which contains a wchar_t or a bigint and then not have any way to tell whether we have a conflict with some other pointer structure on some architectures. On the other hand I suppose you're concerned about the time to do a few comparisons before knowing which length to skip over? I'm not entirely sure cycle-counting at that level leads to the correct conclusions. In particular I think a few checks against constant values followed by a single assignment can actually be cheaper with speculative execution than having to copy data from memory and then do subsequent calculations depending on it. I'm not sure we'll every know though since I doubt it will be measurable. (I'm also not entirely clear which length to put in, the entire length including the header or the length just of the pointer. Personally I think I would prefer just the pointer. I suppose that makes the macro VARSIZE_EXTERNAL_EXHDR_EXHDR() :/ ) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(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