On Tue, Sep 7, 2021 at 11:56 AM Christoph Berg <m...@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
