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 00D83540E4 for ; Tue, 10 May 2005 12:50:06 -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 63938-09 for ; Tue, 10 May 2005 15:49:58 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id C77795406A for ; Tue, 10 May 2005 12:49:56 -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 j4AFno15000595; Tue, 10 May 2005 11:49:50 -0400 (EDT) To: "Jim C. Nasby" Cc: Neil Conway , 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: <20050510153927.GB31103@decibel.org> 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> <20050510153927.GB31103@decibel.org> Comments: In-reply-to "Jim C. Nasby" message dated "Tue, 10 May 2005 10:39:27 -0500" Date: Tue, 10 May 2005 11:49:50 -0400 Message-ID: <594.1115740190@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/489 X-Sequence-Number: 77837 "Jim C. Nasby" writes: > What's the challange to making it adaptive, comming up with an algorithm > that gives you the optimal bucket size (which I would think there's > research on...) or allowing the index to accommodate different bucket > sizes existing in the index at once? (Presumably you don't want to > re-write the entire index every time it looks like a different bucket > size would help.) Exactly. That's (a) expensive and (b) really hard to fit into the WAL paradigm --- I think we could only handle it as a REINDEX. So if it were adaptive at all I think we'd have to support multiple bucket sizes existing simultaneously in the index, and I do not see a good way to do that. Allowing a bucket size to be specified at CREATE INDEX doesn't seem out of line though. We'd have to think up a scheme for index-AM-specific index parameters ... regards, tom lane