X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 26F1B11F6089 for ; Tue, 18 Apr 2006 12:45:50 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 required=5 tests=[AWL=0.127] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 2m1Crr31jV3r for ; Tue, 18 Apr 2006 12:45:43 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 9B6D711F608B for ; Tue, 18 Apr 2006 12:45:42 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k3IFjdkx013755; Tue, 18 Apr 2006 11:45:39 -0400 (EDT) To: "Tarabas (Manuel Rorarius)" cc: pgsql-performance@postgresql.org Subject: Re: Problem with LIKE-Performance In-reply-to: <653249740.20060418173459@tarabas.de> References: <341367953.20060418163513@tarabas.de> <13458.1145373620@sss.pgh.pa.us> <653249740.20060418173459@tarabas.de> Comments: In-reply-to "Tarabas (Manuel Rorarius)" message dated "Tue, 18 Apr 2006 17:34:59 +0200" Date: Tue, 18 Apr 2006 11:45:39 -0400 Message-ID: <13754.1145375139@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200604/382 X-Sequence-Number: 18466 "Tarabas (Manuel Rorarius)" writes: > After removing the enable_seqscan = off and making sure it was gone, > it is a lot faster again. > Now it takes about 469.841 ms for the select. Um, no, enable_seqscan would certainly not have had any effect on the *actual* runtime of this query. All that enable_seqscan = off really does is to add a large constant to the estimated cost of any seqscan, so as to prevent the planner from selecting it unless there is no other alternative plan available. But that has nothing to do with how long the seqscan will really run. If you are seeing a speedup in repeated executions of the same seqscan plan, it's probably just a caching effect. As already noted, it might be worth your while to add an index using the pattern-ops opclass to help with queries like this. regards, tom lane