Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aJL0E-0003Rw-Uf for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Jan 2016 12:58:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aJL0E-0003Is-Cp for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Jan 2016 12:58:18 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aJKyu-0001pB-3H for pgsql-hackers@postgresql.org; Wed, 13 Jan 2016 12:56:56 +0000 Received: from newmail.postgrespro.ru ([93.174.131.138] helo=mail.postgrespro.ru) by makus.postgresql.org with esmtp (Exim 4.84) (envelope-from ) id 1aJKyq-0003b2-UR for pgsql-hackers@postgresql.org; Wed, 13 Jan 2016 12:56:54 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id BEDC121C57C0 for ; Wed, 13 Jan 2016 15:56:50 +0300 (MSK) Received: from mail.postgrespro.ru ([127.0.0.1]) by localhost (mail.postgrespro.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGPYPuBtx3gX for ; Wed, 13 Jan 2016 15:56:49 +0300 (MSK) Received: from [192.168.27.79] (unknown [192.168.27.1]) by mail.postgrespro.ru (Postfix) with ESMTPSA id 9097021C5764 for ; Wed, 13 Jan 2016 15:56:49 +0300 (MSK) Subject: Re: WIP: Covering + unique indexes. To: pgsql-hackers@postgresql.org References: <56167F09.3090101@postgrespro.ru> <56168952.4010101@postgrespro.ru> <5617DAA3.6080408@postgrespro.ru> <565D9859.3040405@postgrespro.ru> <569530FC.2010900@postgrespro.ru> From: Anastasia Lubennikova Message-ID: <56964991.8020705@postgrespro.ru> Date: Wed, 13 Jan 2016 15:56:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030400060506090807060404" X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org This is a multi-part message in MIME format. --------------030400060506090807060404 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 13.01.2016 04:47, David Rowley : > On 13 January 2016 at 06:47, Jeff Janes > wrote: > > > Why is omit_opclass a separate patch? If the included columns now > never participate in the index ordering, shouldn't it be an inherent > property of the main patch that you can "cover" things without btree > opclasses? > > > I don't personally think the covering_unique_4.0.patch is that close > to being too big to review, I think things would make more sense of > the omit_opclass_4.0.patch was included together with this. > I agree that these patches should be merged. It'll be fixed it the next updates. I kept them separate only for historical reasons, it was more convenient for me to debug them. Furthermore, I wanted to show some performance degradation caused by "omit_opclass" and give a way to reproduce it performing test with and whithot the patch. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company --------------030400060506090807060404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

13.01.2016 04:47, David Rowley :
On 13 January 2016 at 06:47, Jeff Janes <jeff.janes@gmail.com> wrote:

Why is omit_opclass a separate patch?  If the included columns now
never participate in the index ordering, shouldn't it be an inherent
property of the main patch that you can "cover" things without btree
opclasses?


I don't personally think the covering_unique_4.0.patch is that close to being too big to review, I think things would make more sense of the omit_opclass_4.0.patch was included together with this.


I agree that these patches should be merged. It'll be fixed it the next updates.
I kept them separate only for historical reasons, it was more convenient for me to debug them. Furthermore, I wanted to show some performance degradation caused by "omit_opclass" and give a way to reproduce it performing test with and whithot the patch.

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--------------030400060506090807060404--