Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 4E3479FBB17 for ; Fri, 30 Mar 2007 03:36:04 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 42361-01 for ; Fri, 30 Mar 2007 03:35:59 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by postgresql.org (Postfix) with ESMTP id 8CDB69FBA33 for ; Fri, 30 Mar 2007 03:36:00 -0300 (ADT) Received: by ug-out-1314.google.com with SMTP id k3so670209ugf for ; Thu, 29 Mar 2007 23:35:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:from; b=hWu/3PiQkg5X0rLuyoDnBT7qQ0SC8OuIu4qxBf5fxHB2PkNyA+IMsLCIttaPLYdD3YexZXqud7tlCjL51kNpcE7g65P56DlCv5uDY2qtcWxAdZn0KQCrTEtop7xQ1TmRUiQ9ZIW+tqrCJFc7kD7omOcWoSQI1XKE65vksrmZUKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:from; b=Pa/kVWV/Uk4t0dedUbOJMOHioCkANC3V2WzsyWe+l1iwK6rQQkmLBMxtyLI9CEi7b2aotqz+IUbmV1rUiI/owPEgKzOWdE1LJ3UO2AKsuQ1DPsQl5RnkVO/GAkVA1JhXwUg3q3sJhKBOwFkMC2QXYzDpQ4ulILn/5JnqRbLM4DI= Received: by 10.67.116.1 with SMTP id t1mr1764514ugm.1175236559147; Thu, 29 Mar 2007 23:35:59 -0700 (PDT) Received: from ?192.168.128.42? ( [62.94.40.205]) by mx.google.com with ESMTP id m1sm2132958ugc.2007.03.29.23.35.57; Thu, 29 Mar 2007 23:35:58 -0700 (PDT) To: pgsql-performance@postgresql.org Subject: Re: Weird performance drop Date: Fri, 30 Mar 2007 08:36:16 +0200 User-Agent: KMail/1.9.5 References: <018c01c77257$cb0bd520$2e00a8c0@tridecap.com> In-Reply-To: <018c01c77257$cb0bd520$2e00a8c0@tridecap.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703300836.16601.Vincenzo.Romano@gmail.com> From: Vincenzo Romano X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200703/433 X-Sequence-Number: 23838 On Friday 30 March 2007 01:12 Dave Dutcher wrote: > > From: pgsql-performance-owner@postgresql.org > > [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of > > Vincenzo Romano > > > > I thought that the query planner usually did a bad job on > > function bodies > > because they'd appear opaque to it. > > In this case it seems to me that the body is opaque only if I > > use the "like" > > operator. > > If you run explain on a query that looks like "select * from a_table where > a_column like 'foo%'" (and you have the appropriate index) you will see > that postgres rewrites the where clause as "a_column >= 'foo' and a_column > < 'fop'". I think your problem is that the query is planned when the > function is created, and at that time postgres doesn't know the value you > are comparing against when you use the like operator, so postgres can't > rewrite the query using >= and <. The problem doesn't happen for plain > equality because postgres doesn't need to know anything about what you are > comparing against in order to use equality. > > Somebody else can correct me if I'm wrong. > > Dave Is there any "workaround"? In my opinion the later the query planner decisions are taken the more effective they can be. It could be an option for the function (body) to delay any query planner decision. -- Vincenzo Romano ---- Maybe Computers will never become as intelligent as Humans. For sure they won't ever become so stupid. [VR-1987]