Re: [HACKERS] Custom compression methods

On Fri, Feb 26, 2021 at 8:10 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Sun, Feb 21, 2021 at 5:33 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
>
> Based on offlist discussion with Robert, I have done further analysis
> of the composite type data. So the Idea is that I have analyzed all
> the callers of
> HeapTupleGetDatum and HeapTupleHeaderGetDatum and divide them into two
> category 1) Callers which are forming the tuple from values that can
> not have compressed/external data.
> 2) Callers which can have external/compressed data

I just realized that there is one more function
"heap_copy_tuple_as_datum" which is flattening the tuple based on the
HeapTupleHasExternal check, so I think I will have to analyze the
caller of this function as well and need to do a similar analysis,
although there are just a few callers for this. And, I think the fix
in ExecEvalConvertRowtype is wrong, we will have to do something for
the compressed type here as well. I am not sure what is the best way
to fix it because we are directly getting the input tuple so we can
not put an optimization of dettoasting before forming the tuple. We
might detoast in execute_attr_map_tuple, when the source and target
row types are different because we are anyway deforming and processing
each filed in that function but the problem is execute_attr_map_tuple
is used at multiple places but for that, we can make another version
of this function which actually detoast along with conversion and use
that in ExecEvalConvertRowtype. But if there is no tuple conversion
needed then we directly use heap_copy_tuple_as_datum and in that case,
there is no deforming at all so maybe, in this case, we can not do
anything but I think ExecEvalConvertRowtype should not be the very
common path.

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