On Tue, Sep 7, 2021 at 11:56 AM Christoph Berg <myon@debian.org> wrote:
> In postgres.h, there are these macros for working with compressed
> toast:
>
> vvvvvvvv
> /* Decompressed size and compression method of an external compressed Datum */
> #define VARDATA_COMPRESSED_GET_EXTSIZE(PTR) \
> (((varattrib_4b *) (PTR))->va_compressed.va_tcinfo & VARLENA_EXTSIZE_MASK)
> #define VARDATA_COMPRESSED_GET_COMPRESS_METHOD(PTR) \
> (((varattrib_4b *) (PTR))->va_compressed.va_tcinfo >> VARLENA_EXTSIZE_BITS)
>
> /* Same, when working directly with a struct varatt_external */
> #define VARATT_EXTERNAL_GET_EXTSIZE(toast_pointer) \
> ((toast_pointer).va_extinfo & VARLENA_EXTSIZE_MASK)
> #define VARATT_EXTERNAL_GET_COMPRESS_METHOD(toast_pointer) \
> ((toast_pointer).va_extinfo >> VARLENA_EXTSIZE_BITS)
>
> On the first line, is the comment "external" correct? It took me quite
> a while to realize that the first two macros are the methods to be
> used on an *inline* compressed Datum, when the second set is used for
> varlenas in toast tables.
Well ... technically the second set are used on a TOAST pointer, which
is not really the same thing as a varlena. The varlena would start
with a 1-byte header identifying it as a TOAST pointer, and then
there'd be a 1-byte saying what kind of TOAST pointer it is, which
would be VARTAG_ONDISK if this is coming from a tuple on disk, and
then the TOAST pointer would start after that. So toast_pointer =
varlena_pointer + 2, if I'm not confused here.
But I agree with you that referring to the argument to
VARDATA_COMPRESSED_GET_EXTSIZE or
VARDATA_COMPRESSED_GET_COMPRESS_METHOD as an "external compressed
Datum" doesn't seem quite right. It is compressed, but it is not
external, at least in the sense that I understand that term.
--
Robert Haas
EDB: http://www.enterprisedb.com
