X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 9BC279FA5D8 for ; Wed, 14 Jun 2006 11:32:54 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 22601-07 for ; Wed, 14 Jun 2006 11:32:50 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.leapfrogonline.com (mail.leapfrogonline.com [69.36.35.239]) by postgresql.org (Postfix) with ESMTP id 680E89F9CAA for ; Wed, 14 Jun 2006 11:32:49 -0300 (ADT) Received: from leapfrogonlinecom-MTA by mail.leapfrogonline.com with Novell_GroupWise; Wed, 14 Jun 2006 09:32:33 -0500 Message-Id: <448FD794.8F27.00A9.0@leapfrogonline.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Beta Date: Wed, 14 Jun 2006 09:32:04 -0500 From: "Shaun Thomas" To: "Tom Lane" Cc: "Jim C. Nasby" , Subject: Re: Confirmation of bad query plan generated by 7.4 References: <9119.1150222168@sss.pgh.pa.us> <448EDFC4.8F27.00A9.0@leapfrogonline.com> <20060613211347.GB34196@pervasive.com> <448EE95D.8F27.00A9.0@leapfrogonline.com> <20060613215418.GI34196@pervasive.com> <448EF8B2.8F27.00A9.0@leapfrogonline.com><448EF8B2.8F27.00A9 In-Reply-To: <448EF8B2.8F27.00A9.0@leapfrogonline.com><448EF8B2.8F27.00A9 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/252 X-Sequence-Number: 19609 >>> On 6/13/2006 at 9:13 PM, Tom Lane wrote: > Read what you wrote, and rethink... Hah. Yes, I understand the irony of that statement, but the point is that the value of the variable won't change during query execution. > If you're desperate you can construct a query string with the variable > value embedded as a literal, and then EXECUTE that. This isn't a great > solution since it forces a re-plan on every execution. That's so gross... but it might work. I'm not really desperate, just frustrated. I really can't wait until we can upgrade; 7.4 is driving me nuts. I'm not really worried about a re-plan, since this SP just updates a fact table, so it only gets called twice a day. Cutting the execution time of the SP down to < 20 seconds from 15 minutes would be nice, but not absolutely required. I was just surprised at the large difference in manual execution as opposed to the SP with the same query. > We've occasionally debated ways to do it better, but no such > improvement will ever appear in 7.4 ;-) Agreed! When we finally upgrade, I fully plan on putting a symbolic bullet into our old installation. ;) Thanks! -- Shaun Thomas Database Administrator Leapfrog Online 807 Greenwood Street Evanston, IL 60201 Tel. 847-440-8253 Fax. 847-570-5750 www.leapfrogonline.com Confidentiality Note: The document(s) accompanying this e-mail transmission, if any, and the e-mail transmittal message contain information from Leapfrog Online Customer Acquisition, LLC is confidential or privileged. The information is intended to be for the use of the individual(s) or entity(ies) named on this e-mail transmission message. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is prohibited. If you have received this e-mail in error, please immediately delete this e-mail and notify us by telephone of the error