Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 72D8264FC0E for ; Tue, 23 Sep 2008 09:17:03 -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 06430-06 for ; Tue, 23 Sep 2008 09:17:00 -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 5E8FF64FC0D for ; Tue, 23 Sep 2008 09:17:00 -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 m8NCGZaD025194; Tue, 23 Sep 2008 08:16:35 -0400 (EDT) To: Simon Riggs cc: "Jonah H. Harris" , Alex Hunsaker , Kenneth Marshall , Xiao Meng , Zdenek Kotala , pgsql-patches@postgresql.org Subject: Re: hash index improving v3 In-reply-to: <1222146936.4445.290.camel@ebony.2ndQuadrant> 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> <17323.1222142759@sss.pgh.pa.us> <1222144262.4445.265.camel@ebony.2ndQuadrant> <18049.1222145316@sss.pgh.pa.us> <1222146936.4445.290.camel@ebony.2ndQuadrant> Comments: In-reply-to Simon Riggs message dated "Tue, 23 Sep 2008 06:15:36 +0100" Date: Tue, 23 Sep 2008 08:16:34 -0400 Message-ID: <25193.1222172194@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/153 X-Sequence-Number: 7168 Simon Riggs writes: > maintenance_work_mem is already used for 3 separate operations that bear > little resemblance to each other. If it's appropriate for all of those > then its appropriate for this usage also. No, it isn't. The fundamental point here is that this isn't a memory allocation parameter; it's a switchover threshold between two different behaviors. regards, tom lane