Thread: Why there is a union in HeapTupleHeaderData struct
Dear Hackers
In fix part oh HeapTuple, there is a union that is named t_choice,{
HeapTupleFields t_heap;
DatumTupleFields t_datum;
} t_choice;
I can't find out why we need t_datum, actually there is no comment about DatumTupleFields.
Regards
Soroosh
Hello,
I think the comment just above the HeapTupleFields struct definition
has the related details.
/** Heap tuple header. To avoid wasting space, the fields should be* laid out in such a way as to avoid structure
padding.**Datums of composite types (row types) share the same general structure* as on-disk tuples, so that the same
routinescan be used to build and* examine them. However the requirements are slightly different: a Datum* does not
needany transaction visibility information, and it does need* a length word and some embedded type information. We can
achievethis* by overlaying the xmin/cmin/xmax/cmax/xvac fields of a heap tuple* with the fields needed in the Datum
case. Typically, all tuples built* in-memory will be initialized with the Datum fields; but when a tuple is* about to
beinserted in a table, the transaction fields will be filled,* overwriting the datum fields.
especially the last line points as to what roles each of them plays,
though, I would like to hear more about additional details from others
who might reply.
On Mon, May 20, 2013 at 4:28 PM, Soroosh Sardari
<soroosh.sardari@gmail.com> wrote:
> Dear Hackers
>
> In fix part oh HeapTuple, there is a union that is named t_choice,
> union
> {
> HeapTupleFields t_heap;
> DatumTupleFields t_datum;
> } t_choice;
>
> I can't find out why we need t_datum, actually there is no comment about
> DatumTupleFields.
>
> Regards
> Soroosh
>
>
--
Amit Langote
Thanks,
If a tuple constructed in memory we don't need t_heap. I have another question,On Mon, May 20, 2013 at 12:46 PM, Amit Langote <amitlangote09@gmail.com> wrote:
Hello,
I think the comment just above the HeapTupleFields struct definition
has the related details.
/*
* Heap tuple header. To avoid wasting space, the fields should be
* laid out in such a way as to avoid structure padding.
*
* Datums of composite types (row types) share the same general structure
* as on-disk tuples, so that the same routines can be used to build and
* examine them. However the requirements are slightly different: a Datum
* does not need any transaction visibility information, and it does need
* a length word and some embedded type information. We can achieve this
* by overlaying the xmin/cmin/xmax/cmax/xvac fields of a heap tuple
* with the fields needed in the Datum case. Typically, all tuples built
* in-memory will be initialized with the Datum fields; but when a tuple is
* about to be inserted in a table, the transaction fields will be filled,
* overwriting the datum fields.
especially the last line points as to what roles each of them plays,
though, I would like to hear more about additional details from others
who might reply.--
On Mon, May 20, 2013 at 4:28 PM, Soroosh Sardari
<soroosh.sardari@gmail.com> wrote:
> Dear Hackers
>
> In fix part oh HeapTuple, there is a union that is named t_choice,
> union
> {
> HeapTupleFields t_heap;
> DatumTupleFields t_datum;
> } t_choice;
>
> I can't find out why we need t_datum, actually there is no comment about
> DatumTupleFields.
>
> Regards
> Soroosh
>
>
Amit Langote
Hello,
I think a more appropriate question to be asked here would be at what
point (in the life of a typical tuple), does a tuple's header contain
t_datum or otherwise, which I would also like to be answered.
On Mon, May 20, 2013 at 6:06 PM, Soroosh Sardari
<soroosh.sardari@gmail.com> wrote:
> Thanks,
>
> If a tuple constructed in memory we don't need t_heap. I have another
> question,
> How make an in-memory tuple?
>
>
>
>
> On Mon, May 20, 2013 at 12:46 PM, Amit Langote <amitlangote09@gmail.com>
> wrote:
>>
>> Hello,
>>
>> I think the comment just above the HeapTupleFields struct definition
>> has the related details.
>>
>> /*
>> * Heap tuple header. To avoid wasting space, the fields should be
>> * laid out in such a way as to avoid structure padding.
>> *
>> * Datums of composite types (row types) share the same general structure
>> * as on-disk tuples, so that the same routines can be used to build and
>> * examine them. However the requirements are slightly different: a Datum
>> * does not need any transaction visibility information, and it does need
>> * a length word and some embedded type information. We can achieve this
>> * by overlaying the xmin/cmin/xmax/cmax/xvac fields of a heap tuple
>> * with the fields needed in the Datum case. Typically, all tuples built
>> * in-memory will be initialized with the Datum fields; but when a tuple
>> is
>> * about to be inserted in a table, the transaction fields will be filled,
>> * overwriting the datum fields.
>>
>>
>> especially the last line points as to what roles each of them plays,
>> though, I would like to hear more about additional details from others
>> who might reply.
>>
>>
>>
>> On Mon, May 20, 2013 at 4:28 PM, Soroosh Sardari
>> <soroosh.sardari@gmail.com> wrote:
>> > Dear Hackers
>> >
>> > In fix part oh HeapTuple, there is a union that is named t_choice,
>> > union
>> > {
>> > HeapTupleFields t_heap;
>> > DatumTupleFields t_datum;
>> > } t_choice;
>> >
>> > I can't find out why we need t_datum, actually there is no comment about
>> > DatumTupleFields.
>> >
>> > Regards
>> > Soroosh
>> >
>> >
>>
>>
>>
>> --
>> Amit Langote
>
>
--
Amit Langote
Wonder though if this question is better asked in pgsql-novice?
On Mon, May 20, 2013 at 9:23 PM, Amit Langote <amitlangote09@gmail.com> wrote:
> Hello,
>
> I think a more appropriate question to be asked here would be at what
> point (in the life of a typical tuple), does a tuple's header contain
> t_datum or otherwise, which I would also like to be answered.
>
> On Mon, May 20, 2013 at 6:06 PM, Soroosh Sardari
> <soroosh.sardari@gmail.com> wrote:
>> Thanks,
>>
>> If a tuple constructed in memory we don't need t_heap. I have another
>> question,
>> How make an in-memory tuple?
>>
>>
>>
>>
>> On Mon, May 20, 2013 at 12:46 PM, Amit Langote <amitlangote09@gmail.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> I think the comment just above the HeapTupleFields struct definition
>>> has the related details.
>>>
>>> /*
>>> * Heap tuple header. To avoid wasting space, the fields should be
>>> * laid out in such a way as to avoid structure padding.
>>> *
>>> * Datums of composite types (row types) share the same general structure
>>> * as on-disk tuples, so that the same routines can be used to build and
>>> * examine them. However the requirements are slightly different: a Datum
>>> * does not need any transaction visibility information, and it does need
>>> * a length word and some embedded type information. We can achieve this
>>> * by overlaying the xmin/cmin/xmax/cmax/xvac fields of a heap tuple
>>> * with the fields needed in the Datum case. Typically, all tuples built
>>> * in-memory will be initialized with the Datum fields; but when a tuple
>>> is
>>> * about to be inserted in a table, the transaction fields will be filled,
>>> * overwriting the datum fields.
>>>
>>>
>>> especially the last line points as to what roles each of them plays,
>>> though, I would like to hear more about additional details from others
>>> who might reply.
>>>
>>>
>>>
>>> On Mon, May 20, 2013 at 4:28 PM, Soroosh Sardari
>>> <soroosh.sardari@gmail.com> wrote:
>>> > Dear Hackers
>>> >
>>> > In fix part oh HeapTuple, there is a union that is named t_choice,
>>> > union
>>> > {
>>> > HeapTupleFields t_heap;
>>> > DatumTupleFields t_datum;
>>> > } t_choice;
>>> >
>>> > I can't find out why we need t_datum, actually there is no comment about
>>> > DatumTupleFields.
>>> >
>>> > Regards
>>> > Soroosh
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Amit Langote
>>
>>
>
>
>
> --
> Amit Langote
--
Amit Langote
Sent from my iPad
On 20-May-2013, at 18:14, Amit Langote <amitlangote09@gmail.com> wrote:
> Wonder though if this question is better asked in pgsql-novice?
>
> On Mon, May 20, 2013 at 9:23 PM, Amit Langote <amitlangote09@gmail.com> wrote:
>> Hello,
>>
>> I think a more appropriate question to be asked here would be at what
>> point (in the life of a typical tuple), does a tuple's header contain
>> t_datum or otherwise, which I would also like to be answered.
>>
>> On Mon, May 20, 2013 at 6:06 PM, Soroosh Sardari
>> <soroosh.sardari@gmail.com> wrote:
>>> Thanks,
>>>
>>> If a tuple constructed in memory we don't need t_heap. I have another
>>> question,
>>> How make an in-memory tuple?
>>>
>>>
>>>
>>>
>>> On Mon, May 20, 2013 at 12:46 PM, Amit Langote <amitlangote09@gmail.com>
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I think the comment just above the HeapTupleFields struct definition
>>>> has the related details.
>>>>
>>>> /*
>>>> * Heap tuple header. To avoid wasting space, the fields should be
>>>> * laid out in such a way as to avoid structure padding.
>>>> *
>>>> * Datums of composite types (row types) share the same general structure
>>>> * as on-disk tuples, so that the same routines can be used to build and
>>>> * examine them. However the requirements are slightly different: a Datum
>>>> * does not need any transaction visibility information, and it does need
>>>> * a length word and some embedded type information. We can achieve this
>>>> * by overlaying the xmin/cmin/xmax/cmax/xvac fields of a heap tuple
>>>> * with the fields needed in the Datum case. Typically, all tuples built
>>>> * in-memory will be initialized with the Datum fields; but when a tuple
>>>> is
>>>> * about to be inserted in a table, the transaction fields will be filled,
>>>> * overwriting the datum fields.
>>>>
>>>>
>>>> especially the last line points as to what roles each of them plays,
>>>> though, I would like to hear more about additional details from others
>>>> who might reply.
>>>>
>>>>
>>>>
>>>> On Mon, May 20, 2013 at 4:28 PM, Soroosh Sardari
>>>> <soroosh.sardari@gmail.com> wrote:
>>>>> Dear Hackers
>>>>>
>>>>> In fix part oh HeapTuple, there is a union that is named t_choice,
>>>>> union
>>>>> {
>>>>> HeapTupleFields t_heap;
>>>>> DatumTupleFields t_datum;
>>>>> } t_choice;
>>>>>
>>>>> I can't find out why we need t_datum, actually there is no comment about
>>>>> DatumTupleFields.
>>>>>
>>>>> Regards
>>>>> Soroosh
>>>>>
>>>>>
I don't think so, as this involves internal structures.Let's keep it here.
Regards,
Atri
Hello, Would you guys please trim the quoted text of the emails you're replying to? I understand Gmail is obnoxious w.r.t. quoted text, but this is starting to become excessive. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Mon, May 20, 2013 at 8:54 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Hello, > > Would you guys please trim the quoted text of the emails you're replying > to? I understand Gmail is obnoxious w.r.t. quoted text, but this is > starting to become excessive. Oops, I didnt notice that. Sorry! Regards, Atri -- Regards, Atri l'apprenant