Message-ID: <ad7c22ce-0e99-45a7-a843-05c7ecdc2826@enterprisedb.com>
Date: Thu, 7 Mar 2024 12:44:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Shared detoast Datum proposal
Content-Language: en-US
To: Nikita Malakhov <hukutoc@gmail.com>
Cc: Andy Fan <zhihuifan1213@163.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
References: <87il4jrk1l.fsf@163.com> <87v87kvboq.fsf@163.com>
 <71321d83-391b-473b-aaf6-618c7f682b96@postgrespro.ru>
 <87r0i7vos3.fsf@163.com> <874je3hcwn.fsf@163.com>
 <c066e988-38b9-460f-9e9d-aedd2482bff2@enterprisedb.com>
 <8734tmg88e.fsf@163.com>
 <7f4c8673-4c5d-4dbf-b8e5-0ec11cd2fba0@enterprisedb.com>
 <87h6i2djf9.fsf@163.com> <87jzms0xza.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>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: 
 <CAN-LCVOMnfGObt-BmRF20qE4Ha3XNDwstrngMHrG-JtJnYfgDQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/ad7c22ce-0e99-45a7-a843-05c7ecdc2826%40enterprisedb.com>
Precedence: bulk

On 3/7/24 08:33, Nikita Malakhov wrote:
> Hi!
> 
> Tomas, I thought about this issue -
>> What if you only need the first slice? In that case decoding everything
>> will be a clear regression.
> And completely agree with you, I'm currently working on it and will post
> a patch a bit later.

Cool. I don't plan to work on improving my patch - it was merely a PoC,
so if you're interested in working on that, that's good.

> Another issue we have here - if we have multiple slices requested -
> then we have to update cached slice from both sides, the beginning
> and the end.
> 

No opinion. I haven't thought about how to handle slices too much.

> On update, yep, you're right
>> Surely the update creates a new TOAST value, with a completely new TOAST
>> pointer, new rows in the TOAST table etc. It's not updated in-place. So
>> it'd end up with two independent entries in the TOAST cache.
> 
>> Or are you interested just in evicting the old value simply to free the
>> memory, because we're not going to need that (now invisible) value? That
>> seems interesting, but if it's too invasive or complex I'd just leave it
>> up to the LRU eviction (at least for v1).
> Again, yes, we do not need the old value after it was updated and
> it is better to take care of it explicitly. It's a simple and not invasive
> addition to your patch.
> 

OK

> Could not agree with you about large values - it makes sense
> to cache large values because the larger it is the more benefit
> we will have from not detoasting it again and again. One way
> is to keep them compressed, but what if we have data with very
> low compression rate?
> 

I'm not against caching large values, but I also think it's not
difficult to construct cases where it's a losing strategy.

> I also changed HASHACTION field value from HASH_ENTER to
> HASH_ENTER_NULL to softly deal with case when we do not
> have enough memory and added checks for if the value was stored
> or not.
> 

I'm not sure about this. HASH_ENTER_NULL is only being used in three
very specific places (two are lock management, one is shmeminitstruct).
This hash table is not unique in any way, so why not to use HASH_ENTER
like 99% other hash tables?


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company