pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andy Fan <zhihuifan1213@163.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nikita Malakhov <hukutoc@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Michael Zhilin <m.zhilin@postgrespro.ru>
Cc: Peter Smith <smithpb2250@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: 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
Message-ID: <874janudgi.fsf@163.com> (raw)
In-Reply-To: <CA+TgmoZfpruG=VvqeKLiRC95VbbxEyxBm8d1r3YOpaedkQuL4A@mail.gmail.com>
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>


Robert Haas <robertmhaas@gmail.com> writes:

> On Wed, May 22, 2024 at 9:46 PM 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. 

-- 
Best Regards
Andy Fan






view thread (53+ messages)  latest in thread

Message-ID: <874janudgi.fsf@163.com>
Permalink:  ../874janudgi.fsf@163.com/
Also on:    postgresql.org/message-id/874janudgi.fsf@163.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: zhihuifan1213@163.com, robertmhaas@gmail.com, hukutoc@gmail.com, tomas.vondra@enterprisedb.com, m.zhilin@postgrespro.ru, smithpb2250@gmail.com, vignesh21@gmail.com, boekewurm+postgres@gmail.com, andres@anarazel.de
  Subject: Re: Shared detoast Datum proposal
  In-Reply-To: <874janudgi.fsf@163.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox