X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id E5B73541EE; Tue, 10 May 2005 16:50:26 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 52828-01; Tue, 10 May 2005 19:50:24 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id 252E7538C9; Tue, 10 May 2005 16:50:22 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j4AJo57t025691; Tue, 10 May 2005 15:50:05 -0400 (EDT) To: Greg Stark Cc: Neil Conway , "Jim C. Nasby" , Christopher Petrilli , Ying Lu , pgsql-general@postgresql.org, pgsql-performance@postgresql.org Subject: Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL In-reply-to: <87wtq7q8zk.fsf@stark.xeocode.com> References: <427F6853.90308@cs.concordia.ca> <427F757A.8000407@samurai.com> <59d991c405050908271b55e673@mail.gmail.com> <427F8321.5030702@samurai.com> <20050509163423.GH35026@decibel.org> <427F9211.2090008@samurai.com> <20050509165133.GJ35026@decibel.org> <427FFCD3.1010803@samurai.com> <4407.1115698257@sss.pgh.pa.us> <428037A2.4060304@samurai.com> <6686.1115700888@sss.pgh.pa.us> <878y2nsj7i.fsf@stark.xeocode.com> <9871.1115733198@sss.pgh.pa.us> <87wtq7q8zk.fsf@stark.xeocode.com> Comments: In-reply-to Greg Stark message dated "10 May 2005 13:35:59 -0400" Date: Tue, 10 May 2005 15:50:05 -0400 Message-ID: <25690.1115754605@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.007 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200505/504 X-Sequence-Number: 77852 Greg Stark writes: >>> What if the hash index stored *only* the hash code? That could be useful for >>> indexing large datatypes that would otherwise create large indexes. >> >> Hmm, that could be a thought. > Hm, if you go this route of having hash indexes store tuples ordered by hash > code and storing the hash code in the index, then it seems hash indexes become > just a macro for a btree index of HASH(index columns). No, not at all, because searching such an index will require a tree descent, thus negating the one true advantage of hash indexes. I see the potential value of sorting by hashcode within an individual page, but that doesn't mean we should do the same across the whole index. regards, tom lane