Re: [HACKERS] Custom compression methods

On Mon, Mar 1, 2021 at 8:53 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> Now, I think the only pending thing is related to the expandedrecord,
> basically, currently, we have detoasted the compressed filed only in
> expanded_record_set_field_internal function. I am still not
> completely sure that for the built-in types do we need to do something
> for expanded_record_set_tuple and expanded_record_set_field or not, I
> mean in these functions do we only expand the external to survive the
> COMMIT/ROLLBACK or do we also expand it send it to some target table
> like we do in expanded_record_set_field_internal.

I have done further analysis of the compressed field in the
expandedrecord. My observation is that only in
expanded_record_set_field_internal we unconditionally pass true and
only when it is called from ER_get_flat_size. In all the other
functions (expanded_record_set_tuple and expanded_record_set_fields)
we only pass expand_external to true if estate->atomic is not set.
And, the estate->atomic is set to false only if we are executing the
anonymous block from a transaction block (there might be another way
to have estate->atomic as false). But the point is that the
flattening in these two functions are conditional which means we can
not use these expanded records to form some kind of row, otherwise, we
can not have the conditional flattening based on the way how the PL
block is being executed, so I think this proves Robert's point that we
are expanding this only for surviving the commit/rollback inside the
PL block. That means for the built-in types, decompression in
expanded_record_set_field_internal should be sufficient and that was
already done in my latest version of patch v29-0001.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com