| From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PROPOSAL] Covering + unique indexes. |
| Date: | 2015-09-14 18:57:53 |
| Message-ID: | 55F718B1.8030306@sigaev.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2015-09-14 18:59:33 | Re: jsonb_set array append hack? |
| Previous Message | Thomas Munro | 2015-09-14 18:50:00 | Re: [PROPOSAL] Covering + unique indexes. |