On Thu, Aug 6, 2015 at 4:09 AM, Vignesh Raghunathan <vignesh.pg...@gmail.com> wrote: > Hello, > > In the function heap_deform_tuple, there is a comment before caching varlena > attributes specifying that the offset will be valid for either an aligned or > unaligned value if there are no padding bytes. Could someone please > elaborate on this?
In PostgreSQL tuple can contain two types of varlena headers. Those are short varlena(doesn't need any alignment) and 4-byte varlena(needs alignment). Refer the function "heap_fill_tuple" to see how the tuple is constructed. For short varlena headers, even if the alignment suggests to do the alignment, we shouldn't not do. Because of this reason instead of "att_align_nominal", the "att_align_pointer" is called. The following is the comment from "att_align_pointer" macro which gives the details why we should use this macro instead of "att_align_nominal". * (A zero byte must be either a pad byte, or the first byte of a correctly * aligned 4-byte length word; in either case we can align safely. A non-zero * byte must be either a 1-byte length word, or the first byte of a correctly * aligned 4-byte length word; in either case we need not align.) > Also, why is it safe to call att_align_nominal if the attribute is not > varlena? Couldn't att_align_pointer be called for both cases? I am not able > to understand how att_align_nominal is faster. All other types definitely needs either char or int or double alignment. Because of this reason it is safe to use the att_align_nominal macro. Please refer the function "heap_fill_tuple" for more details. Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
