From: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Subject: | Re: (9.1) btree_gist support for searching on "not equals" |
Date: | 2010-05-25 01:03:22 |
Message-ID: | 20100525100322.CF3F.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> wrote:
> On 5/21/10 11:47 PM +0300, Jeff Davis wrote:
> > It also allows you to enforce the constraint that only one tuple exists
> > in a table by doing something like:
> >
> > create table a
> > (
> > i int,
> > exclude using gist (i with<>),
> > unique (i)
> > );
+1. I've not read the code, but it might be considerable that we can
abort index scans if we find a first index entry for "i". While we must
scan all candidates for "WHERE i <> ?", but we can abort for the constraint
case because we know existing values are all the same.
> FWIW, this is achievable a lot more easily:
> CREATE UNIQUE INDEX "a_single_row" ON a ((1));
The former exclusion constraint means "one same value for all rows",
but your alternative means "a_single_row", right?
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | KaiGai Kohei | 2010-05-25 01:08:38 | Re: ExecutorCheckPerms() hook |
Previous Message | KaiGai Kohei | 2010-05-25 00:37:01 | Re: ExecutorCheckPerms() hook |