Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1j7CGU-00026b-4q for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Feb 2020 06:03:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j7CGS-0001zt-Os for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Feb 2020 06:03:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j7CGS-0001zj-GQ for pgsql-hackers@lists.postgresql.org; Thu, 27 Feb 2020 06:03:16 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j7CGP-00009n-Rw for pgsql-hackers@lists.postgresql.org; Thu, 27 Feb 2020 06:03:16 +0000 Received: from hnk.local (sp49-97-94-11.msc.spmode.ne.jp [49.97.94.11]) by oss.nttdata.com (Postfix) with ESMTPSA id 58795602D0; Thu, 27 Feb 2020 15:03:08 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.101.5 at oss.nttdata.com Subject: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index. To: Peter Geoghegan , Anastasia Lubennikova Cc: Heikki Linnakangas , PostgreSQL Hackers , =?UTF-8?B?0K7RgNC40Lkg0KHQvtC60L7Qu9C+0LI=?= References: <55E4051B.7020209@postgrespro.ru> <5b5a470b-89d7-7177-29c2-2f907f3f441a@iki.fi> From: Fujii Masao Message-ID: <18f07ae8-7d89-537c-b0a9-54100a1b46da@oss.nttdata.com> Date: Thu, 27 Feb 2020 15:03:07 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/02/27 7:43, Peter Geoghegan wrote: > On Mon, Feb 24, 2020 at 4:54 PM Peter Geoghegan wrote: >> Attached is v34, which has this change. My plan is to commit something >> very close to this on Wednesday morning (barring any objections). > > Pushed. Thanks for committing this nice feature! Here is one minor comment. + deduplicate_items + storage parameter This should be deduplicate_items storage parameter for reloption is necessary only when the GUC parameter with the same name of the reloption exists. So, for example, you can see that is used in vacuum_cleanup_index_scale_factor but not in buffering reloption. Regards, -- Fujii Masao NTT DATA CORPORATION Advanced Platform Technology Group Research and Development Headquarters