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

help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Nikita Malakhov <hukutoc@gmail.com>
Cc: Andy Fan <zhihuifan1213@163.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
Subject: Re: Shared detoast Datum proposal
Date: Thu, 7 Mar 2024 12:44:41 +0100
Message-ID: <ad7c22ce-0e99-45a7-a843-05c7ecdc2826@enterprisedb.com> (raw)
In-Reply-To: <CAN-LCVOMnfGObt-BmRF20qE4Ha3XNDwstrngMHrG-JtJnYfgDQ@mail.gmail.com>
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>

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





view thread (53+ messages)  latest in thread

Message-ID: <ad7c22ce-0e99-45a7-a843-05c7ecdc2826@enterprisedb.com>
Permalink:  ../ad7c22ce-0e99-45a7-a843-05c7ecdc2826@enterprisedb.com/
Also on:    postgresql.org/message-id/ad7c22ce-0e99-45a7-a843-05c7ecdc2826@enterprisedb.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: tomas.vondra@enterprisedb.com, hukutoc@gmail.com, zhihuifan1213@163.com, m.zhilin@postgrespro.ru, smithpb2250@gmail.com, vignesh21@gmail.com, boekewurm+postgres@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: Shared detoast Datum proposal
  In-Reply-To: <ad7c22ce-0e99-45a7-a843-05c7ecdc2826@enterprisedb.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