Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1a4tia-0002Pk-Rf for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Dec 2015 17:00:24 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1a4tiZ-0007N6-Uq for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Dec 2015 17:00:23 +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 1a4tiZ-0007L2-2I for pgsql-hackers@postgresql.org; Fri, 04 Dec 2015 17:00:23 +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 1a4tiU-00012S-3O for pgsql-hackers@postgresql.org; Fri, 04 Dec 2015 17:00:21 +0000 Received: from [192.168.27.79] (unknown [192.168.27.1]) by mail.postgrespro.ru (Postfix) with ESMTPSA id A340321C3949; Fri, 4 Dec 2015 20:00:16 +0300 (MSK) Subject: Re: WIP: Covering + unique indexes. To: Robert Haas References: <56167F09.3090101@postgrespro.ru> <56168952.4010101@postgrespro.ru> <5617DAA3.6080408@postgrespro.ru> <565D9859.3040405@postgrespro.ru> Cc: "pgsql-hackers@postgresql.org" From: Anastasia Lubennikova Message-ID: <5661C6A0.2020602@postgrespro.ru> Date: Fri, 4 Dec 2015 20:00:16 +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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 03.12.2015 04:03, Robert Haas пишет: > On Tue, Dec 1, 2015 at 7:53 AM, Anastasia Lubennikova > wrote: >> If we don't need c4 as an index scankey, we don't need any btree opclass on >> it. >> But we still want to have it in covering index for queries like >> >> SELECT c4 FROM tbl WHERE c1=1000; // uses the IndexOnlyScan >> SELECT * FROM tbl WHERE c1=1000; // uses the IndexOnlyScan >> >> The patch "optional_opclass" completely ignores opclasses of included >> attributes. > OK, I don't get it. Why have an opclass here at all, even optionally? We haven't opclass on c4 and there's no need to have it. But now (without a patch) it's impossible to create covering index, which contains columns with no opclass for btree. test=# create index on tbl using btree (c1, c4); ERROR: data type box has no default operator class for access method "btree" ComputeIndexAttrs() processes the list of index attributes and trying to get an opclass for each of them via GetIndexOpClass(). The patch drops this check for included attributes. So it makes possible to store any datatype in btree and use IndexOnlyScan advantages. I hope that this helps to clarify. -- Anastasia Lubennikova Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers