| From: | Vik Fearing <vik(at)2ndquadrant(dot)fr> |
|---|---|
| To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(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-15 09:11:07 |
| Message-ID: | 55F7E0AB.3020600@2ndquadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 09/15/2015 10:57 AM, David Rowley wrote:
>> I agree, that form
>> > CREATE UNIQUE INDEX i ON t (f1, f2, f3) INCLUDE (f4)
>> > is clear. f4 will be used in row compare and actually planner will be able
>> > to use it as unique index (f1, f2, f3) with additional f4 or as
>> > as unique index (f1, f2, f3, f4), because uniqueness on (f1, f2, f3) gives
>> > warranty of uniqueness on (f1, f2, f3, f4)
>> >
>> >
> I'd vote for this too. However, INCLUDE does not seem to be a reserved word
> at the moment.
What about CREATE UNIQUE INDEX i ON t (f1, f2, f3) WITH (f4); ?
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2015-09-15 09:18:56 | Re: [PROPOSAL] Covering + unique indexes. |
| Previous Message | Rui Hai Jiang | 2015-09-15 09:07:19 | Could the configure script detect the endianness for a Power CPU with endianness mode change |