From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | 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 06:16:41 |
Message-ID: | 55F7B7C9.6090109@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> CREATE INDEX ... ON table (f1, f2, f3) UNIQUE(f1, f2) INCLUDE(f4);
I don't see an advantage this form. What is f3 column? just order? and
f4 will not be used for compare? At least now it requires additional
checks that UNIQUE() fields are the same as first columns in definition.
Non ordering field f4 will require invasive intervention in planner
because now it believes that all columns in btree are ordered.
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)
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2015-09-15 06:24:34 | Re: [PROPOSAL] Covering + unique indexes. |
Previous Message | Teodor Sigaev | 2015-09-15 06:03:00 | Re: Review: GiST support for UUIDs |