From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Amit Kapila <amit.kapila16@gmail.com>,
        Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
        Andrey Borodin <amborodin@acm.org>,
        pgsql-hackers <pgsql-hackers@postgresql.org>,
        Anastasia Lubennikova <lubennikovaav@gmail.com>
Subject: Re: WIP: Covering + unique indexes.
In-reply-to: 
 <CA+TgmobfBMJE6H_L9rcw43h+MOE0nCScY_5n7cdWeE49BKTafw@mail.gmail.com>
References: <56168952.4010101@postgrespro.ru>
 <CA+TgmoZ3SUbfGBFas7=G8Fs5S6uzbqgrWE_PFwQPD-=E7-2EOA@mail.gmail.com>
 <20160814171131.21390.75752.pgcf@coridan.postgresql.org>
 <f90aa60a-b67f-95b5-d9f5-f5d8ced178c6@postgrespro.ru>
 <CAA4eK1+0jLkz8P7MVsUAj+RHmXm4BWBjV8Cc+_-Hsyhgth9ELA@mail.gmail.com>
 <e3d49c6f-3d66-ffa3-29ad-c4719350f049@postgrespro.ru>
 <CAA4eK1KJNTrfrO9P2cY2kKGejXGMrOYMyAERqa1z7nkM4AzT7Q@mail.gmail.com>
 <8d6b5b13-9c41-bd41-9c86-497e4e6a46ab@postgrespro.ru>
 <CAA4eK1JQ3=Fur6NofmrDXnxm90s39GAxJUCFY3ORAQd9aPozvQ@mail.gmail.com>
 <374642a5-b84e-faab-5d5c-18e558bde195@postgrespro.ru>
 <CA+Tgmoa7=OtbYrAnbxwanjbvqMZoy+aDhzy186u+TVJQrpRxmQ@mail.gmail.com>
 <CAA4eK1KnxpoiNNm-cpXEkvOwYxmioeZ5X7_yJU3cVcv6dQFMgA@mail.gmail.com>
 <CA+TgmoaV+nTh=EFKRbHS1-4onOQ-bXOZtON7cuqn2WpNLeUeTg@mail.gmail.com>
 <CAA4eK1LZwHrH05FY49ctwZROvZDqwNBhPLZhb28DGxATjpnkhg@mail.gmail.com>
 <CA+TgmobfBMJE6H_L9rcw43h+MOE0nCScY_5n7cdWeE49BKTafw@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Wed, 05 Oct 2016 12:59:41 -0400"
Date: Wed, 05 Oct 2016 14:44:53 -0400
Message-ID: <23491.1475693093@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Oct 5, 2016 at 9:04 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> Okay, but in that case I think we don't need to store including
>> columns in non-leaf pages to get the exact ordering.  As mentioned
>> upthread, we can use truncated scan key to reach to leaf level and
>> then use the complete key to find the exact location to store the key.
>> This is only possible if there exists an opclass for columns that are
>> covered as part of including clause.  So, we can allow "order by" to
>> use index scan only if the columns covered in included clause have
>> opclass for btree.

> But what if there are many pages full of keys that have the same
> values for the non-INCLUDING columns?

I concur with Robert that INCLUDING columns should be just dead weight
as far as the index is concerned.  Even if opclass information is
available for them, it's overcomplication for too little return.  We do
not need three classes of columns in an index.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers