* Tom Lane:
> I ran into an interesting failure here on HPPA: the code the compiler
> generated for copying unaligned toast pointers into aligned local
> variables failed, because it was assuming halfword (2-byte) alignment of
> the data to be copied! (Instead of a memcpy call it was generating a
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> Why do you cast arguments to memcmp to char* ?
>>
>> Well, *I* haven't done it in a long time,
> I'm referring to tuptoaster.c:488
Oh, I'm sorry, I thought you wer
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Why do you cast arguments to memcmp to char* ?
>
> Well, *I* haven't done it in a long time,
I'm referring to tuptoaster.c:488
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
-
Gregory Stark <[EMAIL PROTECTED]> writes:
> Why do you cast arguments to memcmp to char* ?
Well, *I* haven't done it in a long time, but it used to be a fairly
standard thing. I imagine that back before memcpy was usually declared
with void * arguments, it was necessary to avoid compiler warnings
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Apparently gcc's thought process is "the pointer is declared as struct
> varlena *, therefore must be at least 4-aligned, therefore the data at
> offset 2 is at least 2-aligned". The intermediate cast to "varattrib_1b_e *"
> did not prevent this; I had to a
Gregory Stark <[EMAIL PROTECTED]> writes:
> Here's a patch that does all of the above.
Applied with tweak to use the added byte as an actual length word.
I ran into an interesting failure here on HPPA: the code the compiler
generated for copying unaligned toast pointers into aligned local
variab
Gregory Stark <[EMAIL PROTECTED]> writes:
> "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 decid
"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 noth
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> 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
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I'm wondering whether it doesn't make sense to lower VARATT_SHORT_MAX to 0x70
>> to allow for at least a small number of constant values which could indicate
>> some special type of datum. That could be used to i
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
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I'm wondering whether it doesn't make sense to lower VARATT_SHORT_MAX to 0x70
>> to allow for at least a small number of constant values which could indicate
>> some special type of datum. That could be used to i
Gregory Stark <[EMAIL PROTECTED]> writes:
> I'm wondering whether it doesn't make sense to lower VARATT_SHORT_MAX to 0x70
> to allow for at least a small number of constant values which could indicate
> some special type of datum. That could be used to indicate that a fixed size
> pointer like a to
A while back in an off-hand comment Tom packed varlenas he mentioned that we
might want to have more types of toast pointers. Since then the idea of some
alternative column-wise partitioning scheme has come up and another idea I've
been tossing around is some kind of compression scheme which takes
14 matches
Mail list logo
