Gregory Stark <[EMAIL PROTECTED]> writes:
> I could do the janitorial work again if we're interested.
I think it'd make more sense to do it incrementally rather than in one
big-bang patch ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Tom Lane <[EMAIL PROTECTED]> writes:
>>> BTW, there are at least two copies of that code to be changed. I'd
>>> suggest grepping for assignments to t_hoff to be sure there aren't more.
>
>> I did send in a patch a
Tom Lane escribió:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> BTW, there are at least two copies of that code to be changed. I'd
> >> suggest grepping for assignments to t_hoff to be sure there aren't more.
Besides heap_form_tuple and heap_formtuple,
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> BTW, there are at least two copies of that code to be changed. I'd
>> suggest grepping for assignments to t_hoff to be sure there aren't more.
> I did send in a patch a while ago to get rid of the old HeapFormTupl
Tom Lane <[EMAIL PROTECTED]> writes:
> BTW, there are at least two copies of that code to be changed. I'd
> suggest grepping for assignments to t_hoff to be sure there aren't more.
I did send in a patch a while ago to get rid of the old HeapFormTuple() and
friends.
--
Gregory Stark
Enterpr
Hello Tom,
> Well, as Greg pointed out, setting t_hoff correctly should be sufficient
> for squeezing out useless padding between the tuple header and the tuple
> data. The real objection here is that that's leaving most of the
> possible gain still on the table. The tuple *as a whole* (header a
Hello Greg,
On Tue, Sep 2, 2008 at 9:54 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Ryan Bradetich" <[EMAIL PROTECTED]> writes:
> The structure on the page is to have a bunch of tuples stored one after the
> other. Each tuple is maxaligned after the previous (actually before the
> previous sin
Gregory Stark <[EMAIL PROTECTED]> writes:
> The other 4 bytes you could save is by packing the whole tuples themselves
> more closely on the page. That happens when the item pointer is added and
> pointed to the tuple. To do that heap_form_tuple would have to return data
> back to the caller about
"Ryan Bradetich" <[EMAIL PROTECTED]> writes:
> On Tue, Sep 2, 2008 at 8:07 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> It's conceivable that we could make this work if we wanted to dedicate
>> an infomask bit to showing whether the tuple needs int or double
>> alignment. I don't really think it's w
"Ryan Bradetich" <[EMAIL PROTECTED]> writes:
> Hello Greg,
>
> On Tue, Sep 2, 2008 at 8:30 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>>
>> But I'm confused. You seem to be tweaking the alignment of the data inside
>> the
>> tuple? After the tuple header? I thought we had only one byte of waste
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> In particular, how would code *reading* the tuple know where the
>> data starts?
> Uh, at t_hoff, no?
Doh, right. Obviously need more caffeine.
regards, tom lane
--
Sent via pgsql-hac
Hello Greg,
On Tue, Sep 2, 2008 at 8:30 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Ryan Bradetich" <[EMAIL PROTECTED]> writes:
>
>>4. If require_max_align = true, use the MAXALIGN macro; otherwise
>> use the INTALIGN macro.
>
> Huh, I didn't think of doing it like that.
>
> But I'm confus
Hello Tom,
On Tue, Sep 2, 2008 at 8:07 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Ryan Bradetich" <[EMAIL PROTECTED]> writes:
>> The patch concept is fairly simple.
>
>>1. Add a new boolean local variable: require_max_align
>> (initialized to false).
>
> This really can't possibly work, becau
Hello Martijn,
> You need to arrange testing on an architechture that has strict
> alignment reuiqrements. For example i386 doesn't care about alignment
> at all and will anything from anywhere, with performance degradation.
>
> Other architechtures will simply throw exceptions, that's the smoke
>
Tom Lane <[EMAIL PROTECTED]> writes:
> "Ryan Bradetich" <[EMAIL PROTECTED]> writes:
>> The patch concept is fairly simple.
>
>>1. Add a new boolean local variable: require_max_align
>> (initialized to false).
>
> This really can't possibly work, because you'd need to propagate
> knowledge of
"Ryan Bradetich" <[EMAIL PROTECTED]> writes:
>4. If require_max_align = true, use the MAXALIGN macro; otherwise
> use the INTALIGN macro.
Huh, I didn't think of doing it like that.
But I'm confused. You seem to be tweaking the alignment of the data inside the
tuple? After the tuple header? I
"Ryan Bradetich" <[EMAIL PROTECTED]> writes:
> The patch concept is fairly simple.
>1. Add a new boolean local variable: require_max_align
> (initialized to false).
This really can't possibly work, because you'd need to propagate
knowledge of the tuple's alignment requirement all over the pl
On Tue, Sep 02, 2008 at 01:49:43AM -0700, Ryan Bradetich wrote:
> For fun, I looked around in heap_form_tuple() today to see how big of a job
> this
> change would be. It did not seem very hard to implement. I know there are
> probably several other places I missed with this patch, but this pat
Hello all,
On Mon, Aug 11, 2008 at 2:24 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "Ryan Bradetich" <[EMAIL PROTECTED]> writes:
>
> > After a cursory glance at the HeapTupleHeaderData structure, it appears it
> > could be aligned with INTALIGN instead of MAXALIGN. The one structure I was
> >
Hello Greg,
On Mon, Aug 11, 2008 at 2:24 AM, Gregory Stark <[EMAIL PROTECTED]>wrote:
> "Ryan Bradetich" <[EMAIL PROTECTED]> writes:
>
> > After a cursory glance at the HeapTupleHeaderData structure, it appears
> it
> > could be aligned with INTALIGN instead of MAXALIGN. The one structure I
> was
"Ryan Bradetich" <[EMAIL PROTECTED]> writes:
> After a cursory glance at the HeapTupleHeaderData structure, it appears it
> could be aligned with INTALIGN instead of MAXALIGN. The one structure I was
> worried about was the 6 byte t_ctid structure. The comments in
> src/include/storage/itemptr.h f
Hello all,
I have been digging into the database page layout (specifically the tuples)
to ensure the unsigned integer types were consuming the proper storage.
While digging around, I found one thing surprising:
It appears the heap tuples are padded at the end to the MAXALIGN distance.
Below is m
22 matches
Mail list logo
