Re: (9.1) btree_gist support for searching on "not equals"

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

In response to

Browse pgsql-hackers by date

  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