pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Cc: Andrey Borodin <amborodin@acm.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Anastasia Lubennikova <lubennikovaav@gmail.com>
Subject: Re: WIP: Covering + unique indexes.
Date: Wed, 05 Oct 2016 14:44:53 -0400
Message-ID: <23491.1475693093@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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



view thread (217+ messages)  latest in thread

Message-ID: <23491.1475693093@sss.pgh.pa.us>
Permalink:  ../23491.1475693093@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/23491.1475693093@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, amit.kapila16@gmail.com, a.lubennikova@postgrespro.ru, amborodin@acm.org, lubennikovaav@gmail.com
  Subject: Re: WIP: Covering + unique indexes.
  In-Reply-To: <23491.1475693093@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox