References: <87il4jrk1l.fsf@163.com>
 <CAN-LCVMU_AzYNDQ-MgX3xc5qCnhTgO1LWKUCygOu3neBM-y94g@mail.gmail.com>
 <87frxf1gld.fsf@163.com>
 <fea81484-09b5-499d-80d0-acb8df43d047@enterprisedb.com>
 <875xyb1a6q.fsf@163.com>
 <a595a888-1dde-42a0-becd-c9c313ac781a@enterprisedb.com>
 <87zfvedbsr.fsf@163.com>
 <a70cfbef-45ae-4056-9c3d-cc6191ebc001@enterprisedb.com>
 <87y1axc1o1.fsf@163.com>
 <05aca065-f1f1-48af-b0e8-5eaa72ee6b6f@enterprisedb.com>
 <87ttllbd00.fsf@163.com>
 <CAN-LCVMpvTaWDO6RSKzS4D_-PVTnezRcVgP2O_ciUQiMuMFA1A@mail.gmail.com>
 <233cce7b-d9ae-4605-9b76-1f3b98cbc7f0@enterprisedb.com>
 <CAN-LCVOMnfGObt-BmRF20qE4Ha3XNDwstrngMHrG-JtJnYfgDQ@mail.gmail.com>
 <ad7c22ce-0e99-45a7-a843-05c7ecdc2826@enterprisedb.com>
 <CAN-LCVOSiWpZrG8F0zDFzE+q=Lp0GM=u5cL2hez=8czPD6Pk9w@mail.gmail.com>
 <CA+TgmoZaY5P=McfT7U=EL0GnNMATS8p=CktRN3MQN5=Z+Z8GuQ@mail.gmail.com>
 <875xv6k3k1.fsf@163.com>
 <CA+TgmoaJJ-wFdim=NC6Da5AsmfWMG2N_B9Gm8GwLdy=VO1TCUA@mail.gmail.com>
 <87ikz5i9m1.fsf@163.com>
 <CA+TgmoZfpruG=VvqeKLiRC95VbbxEyxBm8d1r3YOpaedkQuL4A@mail.gmail.com>
User-agent: mu4e 1.10.7; emacs 29.1
From: Andy Fan <zhihuifan1213@163.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nikita Malakhov <hukutoc@gmail.com>, Tomas Vondra
 <tomas.vondra@enterprisedb.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, Andres Freund <andres@anarazel.de>
Subject: Re: Shared detoast Datum proposal
Date: Fri, 24 May 2024 02:46:38 +0000
In-reply-to: 
 <CA+TgmoZfpruG=VvqeKLiRC95VbbxEyxBm8d1r3YOpaedkQuL4A@mail.gmail.com>
Message-ID: <874janudgi.fsf@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/874janudgi.fsf%40163.com>
Precedence: bulk


Robert Haas <robertmhaas@gmail.com> writes:

> On Wed, May 22, 2024 at 9:46=E2=80=AFPM Andy Fan <zhihuifan1213@163.com> =
wrote:
>> Please give me one more chance to explain this. What I mean is:
>>
>> Take SELECT f(a) FROM t1 join t2...; for example,
>>
>> When we read the Datum of a Var, we read it from tts->tts_values[*], no
>> matter what kind of TupleTableSlot is.  So if we can put the "detoast
>> datum" back to the "original " tts_values, then nothing need to be
>> changed.
>
> Yeah, I don't think you can do that.
>
>> - Saving the "detoast datum" version into tts_values[*] doesn't break
>>   the above semantic and the ExprEval engine just get a detoast version
>>   so it doesn't need to detoast it again.
>
> I don't think this is true. If it is true, it needs to be extremely
> well-justified. Even if this seems to work in simple cases, I suspect
> there will be cases where it breaks badly, resulting in memory leaks
> or server crashes or some other kind of horrible problem that I can't
> quite imagine. Unfortunately, my knowledge of this code isn't
> fantastic, so I can't say exactly what bad thing will happen, and I
> can't even say with 100% certainty that anything bad will happen, but
> I bet it will. It seems like it goes against everything I understand
> about how TupleTableSlots are supposed to be used. (Andres would be
> the best person to give a definitive answer here.)
>
>> - The keypoint is the memory management and effeiciency. for now I think
>>   all the places where "slot->tts_nvalid" is set to 0 means the
>>   tts_values[*] is no longer validate, then this is the place we should
>>   release the memory for the "detoast datum".  All the other places like
>>   ExecMaterializeSlot or ExecCopySlot also need to think about the
>>   "detoast datum" as well.
>
> This might be a way of addressing some of the issues with this idea,
> but I doubt it will be acceptable. I don't think we want to complicate
> the slot API for this feature. There's too much downside to doing
> that, in terms of performance and understandability.

Thanks for the doubt! Let's see if Andres has time to look at this. I
feel great about the current state.=20

--=20
Best Regards
Andy Fan