Message-ID: <55F718B1.8030306@sigaev.ru>
Date: Mon, 14 Sep 2015 21:57:53 +0300
From: Teodor Sigaev <teodor@sigaev.ru>
User-Agent: Mozilla/5.0 (X11; FreeBSD i386;
 rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1
MIME-Version: 1.0
To: Thomas Munro <thomas.munro@enterprisedb.com>
CC: Jim Nasby <Jim.Nasby@bluetreble.com>,
 Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [PROPOSAL] Covering + unique indexes.
References: <55F2C1BC.3010109@postgrespro.ru>
	<55F2CCD0.7040608@postgrespro.ru>	<55F6F7AD.4080307@BlueTreble.com>
	<55F70D0A.2030503@sigaev.ru>
 <CAEepm=2G4jdaoXHU0PJ7MqLms88==r44z9bvLpnzjyOTDzwAEw@mail.gmail.com>
In-Reply-To: 
 <CAEepm=2G4jdaoXHU0PJ7MqLms88==r44z9bvLpnzjyOTDzwAEw@mail.gmail.com>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

> It surprised me that you can INCLUDE extra columns on non-UNIQUE
> indexes, since you could just add them as regular indexed columns for
> the same effect.  It looks like when you do that in SQL Server, the
> extra columns are only stored on btree leaf pages and so can't be used
> for searching or ordering.  I don't know how useful that is or if we
> would ever want it... but I just wanted to note that difference, and
Agree

> that the proposed UNIQUE ON FIRST n COLUMNS syntax and catalog change
> can't express that.
  Proposal suggests to work only with unique index by exactly your 
reasons above.


-- 
Teodor Sigaev                      E-mail: teodor@sigaev.ru
                                       WWW: http://www.sigaev.ru/


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