Skip site navigation (1) Skip section navigation (2)

Re: hash index concurrency

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: hash index concurrency
Date: 2012-05-31 15:34:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, May 30, 2012 at 12:21:33AM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, May 29, 2012 at 11:21 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> >> 2) Only support bitmap scans and not ordinary tid scans (the way gin
> >> indexes already do).
> > -1 on losing amgettuple.  I regret that we lost that for GIN and I
> > shall regret it more if we lose it anywhere else.
> Not sure that's all that big a deal for hash.  IIRC the only reasons to
> want it are for index-only scans (not possible anyway with hash) and
> exclusion constraints (for which you might as well use a btree, or plain
> index-supported uniqueness if hash had that).

It does via EXCLUDE constraints, so it could with what as far as I've
been able to tell would be some relatively small amount of coding.

dfetter(at)dfetter:5492=# CREATE TABLE foo(i TEXT, EXCLUDE USING HASH(i WITH =));
NOTICE:  CREATE TABLE / EXCLUDE will create implicit index "foo_i_excl" for table "foo"
dfetter(at)dfetter:5492=# insert into foo VALUES (1),(1);
ERROR:  conflicting key value violates exclusion constraint "foo_i_excl"
DETAIL:  Key (i)=(1) conflicts with existing key (i)=(1).

David Fetter <david(at)fetter(dot)org>
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://

Remember to vote!
Consider donating to Postgres:

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2012-05-31 15:55:18
Subject: Re: Draft release notes complete
Previous:From: Peter GeogheganDate: 2012-05-31 15:34:22
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group