Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C0A53632E0F for ; Mon, 17 Aug 2009 15:28:53 -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 30752-05 for ; Mon, 17 Aug 2009 18:28:49 +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 E6F00633CD0 for ; Mon, 17 Aug 2009 15:28:48 -0300 (ADT) Received: by pxi10 with SMTP id 10so1419099pxi.28 for ; Mon, 17 Aug 2009 11:28:47 -0700 (PDT) Received: by 10.114.16.15 with SMTP id 15mr5050870wap.26.1250533726993; Mon, 17 Aug 2009 11:28:46 -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 l27sm10823366waf.20.2009.08.17.11.28.46 (version=SSLv3 cipher=RC4-MD5); Mon, 17 Aug 2009 11:28:46 -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: <4201.1250530640@sss.pgh.pa.us> References: <4201.1250530640@sss.pgh.pa.us> Content-Type: text/plain Date: Mon, 17 Aug 2009 11:29:18 -0700 Message-Id: <1250533758.16514.12.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=-1.117 tagged_above=-10 required=5 tests=BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482 X-Spam-Level: X-Archive-Number: 200908/1283 X-Sequence-Number: 143926 On Mon, 2009-08-17 at 13:37 -0400, Tom Lane wrote: > Thinking about it again, it seems to me that a much narrower patch > could solve the specific forms of the problem that the PostGIS folk > are seeing. Instead of trying to have a general-purpose method of > preventing repeat de-toasting, we could just prevent it for inner > indexscans by having ExecIndexEvalRuntimeKeys() detoast anything it's > passing to the index AM. With this patch, are there still situations where we should be concerned about repeated de-toasting, or does this solve the biggest part of the problem? If so, is it possible that two similar plans for the same query might perform differently due to repeated de-toasting? Regards, Jeff Davis