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

Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Jim C(dot) Nasby" <decibel(at)decibel(dot)org>,Christopher Petrilli <petrilli(at)gmail(dot)com>,Ying Lu <ying_lu(at)cs(dot)concordia(dot)ca>, pgsql-general(at)postgresql(dot)org,pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL
Date: 2005-05-11 13:59:05
Message-ID: 87d5rxrhhy.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-performance
Neil Conway <neilc(at)samurai(dot)com> writes:

> I'm posting mainly because I wasn't sure what to do to avoid false positives in
> the case of hash collisions. In the hash AM code it is somewhat awkward to
> fetch the pointed-to heap tuple and recheck the scankey.[1] I just did the
> first thing that came to mind -- I marked all the hash AM opclasses as "lossy",
> so the index qual is rechecked. This works, but suggestions for a better way to
> do things would be welcome.

I would have thought that would be the only way worth considering.

Consider for example a query involving two or more hash indexes and the new
bitmap indexscan plan. You don't want to fetch the tuples if you can eliminate
them using one of the other indexes. 

-- 
greg


In response to

pgsql-performance by date

Next:From: John A MeinelDate: 2005-05-11 14:04:47
Subject: Re: Optimizer wrongly picks Nested Loop Left Join
Previous:From: Tom LaneDate: 2005-05-11 13:57:07
Subject: Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL

pgsql-general by date

Next:From: Csaba NagyDate: 2005-05-11 14:01:17
Subject: Re: Fixing a too long column value in a before insert
Previous:From: Tom LaneDate: 2005-05-11 13:57:07
Subject: Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL

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