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 6343853FA8; Tue, 10 May 2005 20:56:33 -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 91978-08; Tue, 10 May 2005 23:56:24 +0000 (GMT) Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by svr1.postgresql.org (Postfix) with ESMTP id 8680F53FA5; Tue, 10 May 2005 20:56:23 -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 1DVeaF-0003Dh-00; Tue, 10 May 2005 19:56:15 -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> <87wtq7q8zk.fsf@stark.xeocode.com> <25690.1115754605@sss.pgh.pa.us> In-Reply-To: <25690.1115754605@sss.pgh.pa.us> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 10 May 2005 19:56:15 -0400 Message-ID: <87ll6mr5y8.fsf@stark.xeocode.com> Lines: 17 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/525 X-Sequence-Number: 77873 Tom Lane writes: > No, not at all, because searching such an index will require a tree > descent, thus negating the one true advantage of hash indexes. The hash index still has to do a tree descent, it just has a larger branching factor than the btree index. btree indexes could have a special case hack to optionally use a large branching factor for the root node, effectively turning them into hash indexes. That would be useful for cases where you know the values will be very evenly distributed and won't need to scan ranges, ie, when you're indexing a hash function. -- greg