From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Andy Fan <zhihuifan1213(at)163(dot)com>, Nikita Malakhov <hukutoc(at)gmail(dot)com> |
Cc: | Michael Zhilin <m(dot)zhilin(at)postgrespro(dot)ru>, Peter Smith <smithpb2250(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Shared detoast Datum proposal |
Date: | 2024-03-03 20:08:20 |
Message-ID: | f0297588-2da4-4d0f-9467-aac0ca33c542@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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'm not sure I understand your concerns. I can't speak for others, but I
did not consider you and your proposals too self-opinionated. 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.
FWIW I'm not somehow sure the approach I suggested is guaranteed to be
better than "your" approach. Maybe there's some issue that I missed, for
example.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-03-03 20:29:42 | Re: Shared detoast Datum proposal |
Previous Message | Bharath Rupireddy | 2024-03-03 18:10:00 | Re: Introduce XID age and inactive timeout based replication slot invalidation |