Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 893D46334E9 for ; Mon, 17 Aug 2009 16:10:02 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 08840-05 for ; Mon, 17 Aug 2009 19:09:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-px0-f180.google.com (mail-px0-f180.google.com [209.85.216.180]) by mail.postgresql.org (Postfix) with ESMTP id 7D6A86334D4 for ; Mon, 17 Aug 2009 16:09:51 -0300 (ADT) Received: by pxi10 with SMTP id 10so1437376pxi.28 for ; Mon, 17 Aug 2009 12:09:50 -0700 (PDT) Received: by 10.114.162.26 with SMTP id k26mr915796wae.167.1250536189825; Mon, 17 Aug 2009 12:09:49 -0700 (PDT) Received: from ?10.10.30.183? (204.11.227.33.static.etheric.net [204.11.227.33]) by mx.google.com with ESMTPS id v39sm5207184wah.27.2009.08.17.12.09.48 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Aug 2009 12:09:48 -0700 (PDT) Subject: Re: Another try at reducing repeated detoast work for PostGIS From: Jeff Davis To: Tom Lane Cc: pgsql-hackers@postgreSQL.org In-Reply-To: <5561.1250535244@sss.pgh.pa.us> References: <4201.1250530640@sss.pgh.pa.us> <1250533758.16514.12.camel@monkey-cat.sm.truviso.com> <5561.1250535244@sss.pgh.pa.us> Content-Type: text/plain Date: Mon, 17 Aug 2009 12:10:20 -0700 Message-Id: <1250536220.10782.5.camel@monkey-cat.sm.truviso.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200908/1288 X-Sequence-Number: 143931 On Mon, 2009-08-17 at 14:54 -0400, Tom Lane wrote: > > If so, is it possible that two similar plans for the same query might > > perform differently due to repeated de-toasting? > > Hard to answer that one. What's "similar"? My only concern is that it's a somewhat hidden optimization (not seen in explain output), and thus a potential performance problem might catch someone by surprise. I don't see how that could happen with this particular patch, but I thought I would bring it up in case someone else does. Regards, Jeff Davis