Re: [PROPOSAL] Covering + unique indexes.

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to


Browse pgsql-hackers by date

  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