[HACKERS] Why there is a union in HeapTupleHeaderData struct

2013-05-20 Thread Soroosh Sardari
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


Re: [HACKERS] Why there is a union in HeapTupleHeaderData struct

2013-05-20 Thread Amit Langote
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.sard...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Why there is a union in HeapTupleHeaderData struct

2013-05-20 Thread Soroosh Sardari
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 amitlangot...@gmail.comwrote:

 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.sard...@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



Re: [HACKERS] Why there is a union in HeapTupleHeaderData struct

2013-05-20 Thread 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.sard...@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 amitlangot...@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.sard...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Why there is a union in HeapTupleHeaderData struct

2013-05-20 Thread Amit Langote
Wonder though if this question is better asked in pgsql-novice?

On Mon, May 20, 2013 at 9:23 PM, Amit Langote amitlangot...@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.sard...@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 amitlangot...@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.sard...@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 via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Why there is a union in HeapTupleHeaderData struct

2013-05-20 Thread Atri Sharma


Sent from my iPad

On 20-May-2013, at 18:14, Amit Langote amitlangot...@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 amitlangot...@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.sard...@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 amitlangot...@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.sard...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Why there is a union in HeapTupleHeaderData struct

2013-05-20 Thread Alvaro Herrera
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 Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Why there is a union in HeapTupleHeaderData struct

2013-05-20 Thread Atri Sharma
On Mon, May 20, 2013 at 8:54 PM, Alvaro Herrera
alvhe...@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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers