Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 520D364FC22 for ; Tue, 23 Sep 2008 01:06:12 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 20076-02 for ; Tue, 23 Sep 2008 01:06:04 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 4BF3664FC21 for ; Tue, 23 Sep 2008 01:06:02 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m8N45xVU017324; Tue, 23 Sep 2008 00:05:59 -0400 (EDT) To: "Jonah H. Harris" cc: "Alex Hunsaker" , "Kenneth Marshall" , "Xiao Meng" , "Zdenek Kotala" , pgsql-patches@postgresql.org Subject: Re: hash index improving v3 In-reply-to: <36e682920809222030k49293e85jc57429296c5d2d76@mail.gmail.com> References: <34d269d40809052249h59750f83v4b19a50d0555580@mail.gmail.com> <34d269d40809091823t204e252fl246443be71aed9ff@mail.gmail.com> <20080910130401.GG6714@it.is.rice.edu> <34d269d40809102049y2599a381kf409c0b5f18b6170@mail.gmail.com> <34d269d40809102117g470c4d25l55be7898fc43fc40@mail.gmail.com> <20080911152437.GM6714@it.is.rice.edu> <34d269d40809111951s7bac44cfk5dc9244693dd777c@mail.gmail.com> <20080912142921.GB26773@it.is.rice.edu> <7246.1221445012@sss.pgh.pa.us> <34d269d40809222025k2b2252dft89db471649c8eef8@mail.gmail.com> <36e682920809222030k49293e85jc57429296c5d2d76@mail.gmail.com> Comments: In-reply-to "Jonah H. Harris" message dated "Mon, 22 Sep 2008 23:30:58 -0400" Date: Tue, 23 Sep 2008 00:05:59 -0400 Message-ID: <17323.1222142759@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/149 X-Sequence-Number: 7164 "Jonah H. Harris" writes: > On Mon, Sep 22, 2008 at 11:25 PM, Alex Hunsaker wrote: >> On Sun, Sep 14, 2008 at 8:16 PM, Tom Lane wrote: >>> I'm considering changing hashbuild to switch over at shared_buffers instead >>> of effective_cache_size --- any thoughts about that? >> >> Switching to shared_buffers gets my vote, on my test table with >> 50,000,000 rows it takes about 8 minutes to create an index using the >> default effective_cache_size. With effective_cache_size set to 6GB >> (machine has 8GB) its still going an hour later. > Agreed. I think using shared_buffers as a cutoff is a much better idea as well. Already done in CVS a week or so back, but thanks for following up with some confirmation. regards, tom lane