Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 01FE3634E3B for ; Sat, 22 Aug 2009 16:35:13 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 93249-09 for ; Sat, 22 Aug 2009 19:35:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from is.rice.edu (is.rice.edu [128.42.42.24]) by mail.postgresql.org (Postfix) with ESMTP id 3554C632F22 for ; Sat, 22 Aug 2009 16:35:03 -0300 (ADT) Received: from scan1.mail.rice.edu (scan1.mail.rice.edu [128.42.58.160]) by is.rice.edu (Postfix) with ESMTP id 7B22C419F3; Sat, 22 Aug 2009 14:35:00 -0500 (CDT) Received: from is.rice.edu ([128.42.42.24]) by scan1.mail.rice.edu (scan1.mail.rice.edu [128.42.58.160]) (amavisd-new, port 10024) with ESMTP id 25846-02; Sat, 22 Aug 2009 14:34:59 -0500 (CDT) Received: by is.rice.edu (Postfix, from userid 18612) id B05BE41819; Sat, 22 Aug 2009 14:34:59 -0500 (CDT) Date: Sat, 22 Aug 2009 14:34:57 -0500 From: Kenneth Marshall To: Tom Lane Cc: Mark Cave-Ayland , pgsql-hackers@postgresql.org Subject: Re: Another try at reducing repeated detoast work for PostGIS Message-ID: <20090822193457.GA4268@it.is.rice.edu> References: <4201.1250530640@sss.pgh.pa.us> <4A8A7287.1080208@siriusit.co.uk> <25799.1250616857@sss.pgh.pa.us> <4A8FD328.2030408@siriusit.co.uk> <10470.1250959181@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10470.1250959181@sss.pgh.pa.us> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: by amavis-2.2.1 at scan1.mail.rice.edu X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-6.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 X-Spam-Level: X-Archive-Number: 200908/1560 X-Sequence-Number: 144203 On Sat, Aug 22, 2009 at 12:39:41PM -0400, Tom Lane wrote: > Mark Cave-Ayland writes: > > So in conclusion, I think that patch looks good and that the extra time > > I was seeing was due to RECHECK being applied to the && operator, and > > not the time being spent within the index scan itself. > > Thanks, I appreciate the followup. > > I plan to go ahead and apply the patch to HEAD --- it doesn't conflict > with Heikki's pending patch AFAICS, and no one has suggested an > alternative that seems likely to get implemented soon. > > I am a bit tempted to apply it to 8.4 as well; otherwise the PostGIS > people are likely to start cluttering their code with this > add-a-dummy-function workaround, which would be unproductive in the long > run. Comments? > > regards, tom lane > +1 for applying it to 8.4 as well. Cheers, Ken