On Mon, Mar 1, 2021 at 8:53 PM Dilip Kumar <dilipbal...@gmail.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
