From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Nikita Malakhov <hukutoc(at)gmail(dot)com>, Andy Fan <zhihuifan1213(at)163(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-06 20:42:38 |
Message-ID: | 6feca2da-4818-466f-9374-5cef5bb85383@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/6/24 07:09, Nikita Malakhov wrote:
> Hi,
>
> In addition to the previous message - for the toast_fetch_datum_slice
> the first (seems obvious) way is to detoast the whole value, save it
> to cache and get slices from it on demand. I have another one on my
> mind, but have to play with it first.
>
What if you only need the first slice? In that case decoding everything
will be a clear regression.
IMHO this needs to work like this:
1) check if the cache already has sufficiently large slice detoasted
(and use the cached value if yes)
2) if there's no slice detoasted, or if it's too small, detoast a
sufficiently large slice and store it in the cache (possibly evicting
the already detoasted slice)
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-03-06 20:58:48 | Re: Shared detoast Datum proposal |
Previous Message | Tomas Vondra | 2024-03-06 20:34:37 | Re: [PATCH] Exponential backoff for auth_delay |