Re: Caching offsets of varlena attributes

On Thu, Aug 6, 2015 at 4:09 AM, Vignesh Raghunathan
<vignesh(dot)pgsql(at)gmail(dot)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