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>
To: 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: Wed, 6 Mar 2024 21:42:38 +0100
Message-ID: <6feca2da-4818-466f-9374-5cef5bb85383@enterprisedb.com> (raw)
In-Reply-To: <CAN-LCVNpHNS9yc9B6RFP5Dv_eQcM3yuXzmu-bzr_94Ena6vJQA@mail.gmail.com>
References: <87il4jrk1l.fsf@163.com>
	<CAHut+PsehMtwQ4uE9VS2C7jB1yT0SZVOPU22u1=ma1K7dKFUow@mail.gmail.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>
	<CAN-LCVNpHNS9yc9B6RFP5Dv_eQcM3yuXzmu-bzr_94Ena6vJQA@mail.gmail.com>

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





view thread (53+ messages)  latest in thread

Message-ID: <6feca2da-4818-466f-9374-5cef5bb85383@enterprisedb.com>
Permalink:  ../6feca2da-4818-466f-9374-5cef5bb85383@enterprisedb.com/
Also on:    postgresql.org/message-id/6feca2da-4818-466f-9374-5cef5bb85383@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: <6feca2da-4818-466f-9374-5cef5bb85383@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