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 3AD62542F1; Tue, 10 May 2005 14:36:20 -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 24391-06; Tue, 10 May 2005 17:36:11 +0000 (GMT) Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by svr1.postgresql.org (Postfix) with ESMTP id 3E0CB5422E; Tue, 10 May 2005 14:36:10 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1DVYeG-00012d-00; Tue, 10 May 2005 13:36:00 -0400 To: Tom Lane Cc: Greg Stark , 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 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> In-Reply-To: <9871.1115733198@sss.pgh.pa.us> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 10 May 2005 13:35:59 -0400 Message-ID: <87wtq7q8zk.fsf@stark.xeocode.com> Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.006 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200505/497 X-Sequence-Number: 77845 Tom Lane 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). I'm not saying that to criticize this plan. In fact I think that captures most (though not all) of what a hash index should be. It would be pretty useful. In fact if it isn't how hash indexes are implemented then it might be useful to provide a user visible hash(ROW) function that allows creating such indexes as functional indexes. Though hiding it would make the SQL simpler. -- greg