| From: | Andy Fan <zhihuifan1213(at)163(dot)com> |
|---|---|
| To: | Nikita Malakhov <hukutoc(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, 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 01:52:16 |
| Message-ID: | 87msrgdq93.fsf@163.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
[1] https://www.postgresql.org/message-id/875xyb1a6q.fsf%40163.com
--
Best Regards
Andy Fan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Steve Chavez | 2024-03-03 02:00:30 | psql: fix variable existence tab completion |
| Previous Message | Melanie Plageman | 2024-03-03 00:15:28 | Re: BitmapHeapScan streaming read user and prelim refactoring |