Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSCch-00C2v6-1R for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jan 2024 08:59:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rSCcf-00BAg8-SR for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jan 2024 08:59:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSCcf-00BAg0-AJ for pgsql-hackers@lists.postgresql.org; Tue, 23 Jan 2024 08:59:09 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSCcb-002vul-SN for pgsql-hackers@lists.postgresql.org; Tue, 23 Jan 2024 08:59:08 +0000 Received: from [172.30.9.138] (unknown [172.30.9.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: m.zhilin@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 823EBE20FDC; Tue, 23 Jan 2024 11:59:02 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1706000342; bh=Wuu6EYNBZGT8ymO6NhczNNNqS3qsviGMgYF1EmySE2s=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=Q6+bL/q/ouubi7VcbgSB1E1Eu+nZTvm3Byep7rc1EfUyCGjiyBsBxmcjhVEKgIHhY TbKzCQO2gsthoivhKrMN206xJ1Bk/qHezD6zuCLFl/jUHuzJq2MA3zv4zhNwQVZGSS ldvbKxEvJNsICF9kzrhn/IQI/pk+snhBeZU+jaFirRkSjpKzhR6565OyMK7tV+gyzH 9I1aP1jiqrFTfIjF5wItHetBHPN4l+Q3Rl7nznG3xTKkBvLRq4wDiI7PliM9EeNCgj MlcnuqUQfPUwpGLZ7j1dD/4XOgkdEKN2G724NVVaGGK/eLhVZP4gmRW8tpjIDs54zl E6dQZUcjCQYIQ== Content-Type: multipart/alternative; boundary="------------7uiTyAUirwKGXhv4CSMLqxaU" Message-ID: <71321d83-391b-473b-aaf6-618c7f682b96@postgrespro.ru> Date: Tue, 23 Jan 2024 11:59:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Shared detoast Datum proposal To: Andy Fan , Peter Smith Cc: vignesh C , Matthias van de Meent , Nikita Malakhov , pgsql-hackers@lists.postgresql.org References: <87il4jrk1l.fsf@163.com> <87h6jxw41k.fsf@163.com> <87sf3andy2.fsf@163.com> <87wmskm9qu.fsf@163.com> <87v87kvboq.fsf@163.com> Content-Language: en-US From: Michael Zhilin In-Reply-To: <87v87kvboq.fsf@163.com> X-Virus-Scanned: clamav-milter 0.100.3 at postfix X-Virus-Status: Clean List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------7uiTyAUirwKGXhv4CSMLqxaU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, It looks like v5 is missing in your mail. Could you please check and resend it? Thanks,  Michael. On 1/23/24 08:44, Andy Fan wrote: > Hi, > > Peter Smith writes: > >> 2024-01 Commitfest. >> >> Hi, This patch has a CF status of "Needs Review" [1], but it seems >> there were CFbot test failures last time it was run [2]. Please have a >> look and post an updated version if necessary. >> >> ====== >> [1]https://commitfest.postgresql.org/46/4759/ >> [2]https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/46/4759 > v5 attached, it should fix the above issue. This version also introduce > a data struct called bitset, which has a similar APIs like bitmapset but > have the ability to reset all bits without recycle its allocated memory, > this is important for this feature. > > commit 44754fb03accb0dec9710a962a334ee73eba3c49 (HEAD -> shared_detoast_value_v2) > Author: yizhi.fzh > Date: Tue Jan 23 13:38:34 2024 +0800 > > shared detoast feature. > > commit 14a6eafef9ff4926b8b877d694de476657deee8a > Author: yizhi.fzh > Date: Mon Jan 22 15:48:33 2024 +0800 > > Introduce a Bitset data struct. > > While Bitmapset is designed for variable-length of bits, Bitset is > designed for fixed-length of bits, the fixed length must be specified at > the bitset_init stage and keep unchanged at the whole lifespan. Because > of this, some operations on Bitset is simpler than Bitmapset. > > The bitset_clear unsets all the bits but kept the allocated memory, this > capacity is impossible for bit Bitmapset for some solid reasons and this > is the main reason to add this data struct. > > Also for performance aspect, the functions for Bitset removed some > unlikely checks, instead with some Asserts. > > [1]https://postgr.es/m/CAApHDvpdp9LyAoMXvS7iCX-t3VonQM3fTWCmhconEvORrQ%2BZYA%40mail.gmail.com > [2]https://postgr.es/m/875xzqxbv5.fsf%40163.com > > > I didn't write a good commit message for commit 2, the people who is > interested with this can see the first message in this thread for > explaination. > > I think anyone whose customer uses lots of jsonb probably can get > benefits from this. the precondition is the toast value should be > accessed 1+ times, including the jsonb_out function. I think this would > be not rare to happen. > -- Michael Zhilin Postgres Professional +7(925)3366270 https://www.postgrespro.ru --------------7uiTyAUirwKGXhv4CSMLqxaU Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Andy,

It looks like v5 is missing in your mail. Could you please check and resend it?

Thanks,
 Michael.

On 1/23/24 08:44, Andy Fan wrote:
Hi,

Peter Smith <smithpb2250@gmail.com> writes:


2024-01 Commitfest.

Hi, This patch has a CF status of "Needs Review" [1], but it seems
there were CFbot test failures last time it was run [2]. Please have a
look and post an updated version if necessary.

======
[1] https://commitfest.postgresql.org/46/4759/
[2] https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/46/4759

v5 attached, it should fix the above issue.  This version also introduce
a data struct called bitset, which has a similar APIs like bitmapset but
have the ability to reset all bits without recycle its allocated memory,
this is important for this feature.

commit 44754fb03accb0dec9710a962a334ee73eba3c49 (HEAD -> shared_detoast_value_v2)
Author: yizhi.fzh <yizhi.fzh@alibaba-inc.com>
Date:   Tue Jan 23 13:38:34 2024 +0800

    shared detoast feature.

commit 14a6eafef9ff4926b8b877d694de476657deee8a
Author: yizhi.fzh <yizhi.fzh@alibaba-inc.com>
Date:   Mon Jan 22 15:48:33 2024 +0800

    Introduce a Bitset data struct.
    
    While Bitmapset is designed for variable-length of bits, Bitset is
    designed for fixed-length of bits, the fixed length must be specified at
    the bitset_init stage and keep unchanged at the whole lifespan. Because
    of this, some operations on Bitset is simpler than Bitmapset.
    
    The bitset_clear unsets all the bits but kept the allocated memory, this
    capacity is impossible for bit Bitmapset for some solid reasons and this
    is the main reason to add this data struct.
    
    Also for performance aspect, the functions for Bitset removed some
    unlikely checks, instead with some Asserts.
    
    [1] https://postgr.es/m/CAApHDvpdp9LyAoMXvS7iCX-t3VonQM3fTWCmhconEvORrQ%2BZYA%40mail.gmail.com
    [2] https://postgr.es/m/875xzqxbv5.fsf%40163.com


I didn't write a good commit message for commit 2, the people who is
interested with this can see the first message in this thread for
explaination. 

I think anyone whose customer uses lots of jsonb probably can get
benefits from this. the precondition is the toast value should be
accessed 1+ times, including the jsonb_out function. I think this would
be not rare to happen.



-- 
Michael Zhilin
Postgres Professional
+7(925)3366270
https://www.postgrespro.ru
--------------7uiTyAUirwKGXhv4CSMLqxaU--