References: <87il4jrk1l.fsf@163.com> <87sf3andy2.fsf@163.com>
 <87wmskm9qu.fsf@163.com>
 <CAHut+PsehMtwQ4uE9VS2C7jB1yT0SZVOPU22u1=ma1K7dKFUow@mail.gmail.com>
 <87v87kvboq.fsf@163.com>
 <71321d83-391b-473b-aaf6-618c7f682b96@postgrespro.ru>
 <87r0i7vos3.fsf@163.com> <874je3hcwn.fsf@163.com>
 <c066e988-38b9-460f-9e9d-aedd2482bff2@enterprisedb.com>
 <8734tmg88e.fsf@163.com>
 <7f4c8673-4c5d-4dbf-b8e5-0ec11cd2fba0@enterprisedb.com>
 <87h6i2djf9.fsf@163.com> <87jzms0xza.fsf@163.com>
 <CAN-LCVMU_AzYNDQ-MgX3xc5qCnhTgO1LWKUCygOu3neBM-y94g@mail.gmail.com>
 <87frxf1gld.fsf@163.com>
 <fea81484-09b5-499d-80d0-acb8df43d047@enterprisedb.com>
 <CAN-LCVPv1f0DKk9UvpJ_OnY6CcpNvo7M-RkZVfLi7xRGdBNjqQ@mail.gmail.com>
 <871q8z19ux.fsf@163.com>
 <CAN-LCVON0vAr6tyiK4jsLmkCPd6PxkfxzXDyG8rjM9t3jOVM6g@mail.gmail.com>
 <87msrgdq93.fsf@163.com>
 <f0297588-2da4-4d0f-9467-aac0ca33c542@enterprisedb.com>
User-agent: mu4e 1.10.7; emacs 29.1
From: Andy Fan <zhihuifan1213@163.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Nikita Malakhov <hukutoc@gmail.com>, Michael Zhilin
 <m.zhilin@postgrespro.ru>, Peter Smith <smithpb2250@gmail.com>, vignesh C
 <vignesh21@gmail.com>, Matthias van de Meent
 <boekewurm+postgres@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: Shared detoast Datum proposal
Date: Mon, 04 Mar 2024 09:17:27 +0800
In-reply-to: <f0297588-2da4-4d0f-9467-aac0ca33c542@enterprisedb.com>
Message-ID: <874jdmeqs8.fsf@163.com>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://www.postgresql.org/message-id/874jdmeqs8.fsf%40163.com>
Precedence: bulk


Tomas Vondra <tomas.vondra@enterprisedb.com> writes:

> On 3/3/24 02:52, Andy Fan wrote:
>> 
>> Hi Nikita,
>> 
>>>
>>> Have you considered another one - to alter pg_detoast_datum
>>> (actually, it would be detoast_attr function) and save
>>> detoasted datums in the detoast context derived
>>> from the query context? 
>>>
>>> We have just enough information at this step to identify
>>> the datum - toast relation id and value id, and could
>>> keep links to these detoasted values in a, say, linked list
>>>  or hash table. Thus we would avoid altering the executor
>>> code and all detoast-related code would reside within
>>> the detoast source files?
>> 
>> I think you are talking about the way Tomas provided.  I am really
>> afraid that I was thought of too self-opinionated, but I do have some
>> concerns about this approch as I stated here [1], looks my concerns is
>> still not addressed, or the concerns itself are too absurd which is
>> really possible I think? 
>> 
>
> I can't speak for others, but I did not consider you and your
> proposals too self-opinionated. 

This would be really great to know:)

> You did
> propose a solution that you consider the right one. That's fine. People
> will question that and suggest possible alternatives. That's fine too,
> it's why we have this list in the first place.

I agree.

-- 
Best Regards
Andy Fan