Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UHBZN-0001ta-EB for pgsql-sql@arkaria.postgresql.org; Sun, 17 Mar 2013 11:16:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UHBZM-000207-OH for pgsql-sql@arkaria.postgresql.org; Sun, 17 Mar 2013 11:16:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UHBZK-0001zz-N6 for pgsql-sql@postgresql.org; Sun, 17 Mar 2013 11:16:02 +0000 Received: from mail-bk0-x236.google.com ([2a00:1450:4008:c01::236]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UHBZG-0006Z5-2C for pgsql-sql@postgresql.org; Sun, 17 Mar 2013 11:16:00 +0000 Received: by mail-bk0-f54.google.com with SMTP id w5so2130984bku.27 for ; Sun, 17 Mar 2013 04:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=eOHA4oxEsspOBaItRkEfgWr7QElNJ6biHqcSkMuWp/Y=; b=MYtJnx8Mo6U2/CuAhqhNNHb/JMEE/kWkPyp3qlFfvZm3eT3iioW1T59Ztws9ApcZG4 dWbEcUuLlJI772z5jfTf7IKjhcrJD/quLNxfzaSO3ZMmI0IBWLK5IuQo98NwMQDrcN38 TOS5DOjZefoSBoPRD95shkK1Rk1t11J4BfOaHacz6I0X+pza951KWElyGmzjCqvvIYcQ 5Qp0qSF9Sx7Ph0eC4k6s+8Gc3hPoNFQi0e4uGhOmcLFZnZfdlsLA9cbvc9V/iPVT5PO5 XVwl4Ulj1d8bzT/bfsK6i75OhbkcolCjFTqqhm3wokGp44PudYm4yWFkOGrnaphuozb2 ZbcQ== X-Received: by 10.204.183.198 with SMTP id ch6mr5411633bkb.90.1363518956343; Sun, 17 Mar 2013 04:15:56 -0700 (PDT) Received: from [192.168.0.2] (adsl-ull-75-208.50-151.net24.it. [151.50.208.75]) by mx.google.com with ESMTPS id gm14sm3475073bkc.7.2013.03.17.04.15.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 04:15:55 -0700 (PDT) Message-ID: <5145A5C6.9000703@gmail.com> Date: Sun, 17 Mar 2013 12:15:18 +0100 From: Surfing User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: pgsql-sql@postgresql.org Subject: Efficiency Problem Content-Type: multipart/alternative; boundary="------------060603080809060206020106" X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org This is a multi-part message in MIME format. --------------060603080809060206020106 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi all, I'm composing a query from a web application of type: *SELECT * FROM table WHERE a_text_field LIKE replace_something ('%**/a_given_string/**%');* The function replace_something( ... ) is a stored procedure that replaces some particular characters with others. The problem is that I noticed that this query is inefficient... and I think that the replace_something ( ... ) function is called for each row of the table. This observation is motivated by the fact that it takes around 30 seconds to execute on the table (of about 25,000 rows), whereas if I execute: *SELECT * FROM table WHERE a_text_field LIKE '**/pre_processed_string/**//**';* where/pre_processed_string///is the result of the application of replace_something ('%/a_given_string/%') it just takes 164ms. The execution of *SELECT replace_something ('%**/a_given_string/**%')* takes only 14ms. Summarizing, - Replace function: 14ms - SELECT query without replace function: 164ms - SELECT query with replace function: 30.000ms Morever, I cannot create a stored procedure that precalculate the /pre_processed_string /and executes the query, since I dinamically compose other conditions in the WHERE clause. Any suggestion? Thank you. // --------------060603080809060206020106 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Hi all,
    I'm composing a query from a web application of type:

    SELECT * FROM table WHERE a_text_field LIKE replace_something ('%a_given_string%');

The function replace_something( ... ) is a stored procedure that replaces some particular characters with others.
The problem is that I noticed that this query is inefficient... and I think that the replace_something ( ... ) function is called for each row of the table.

This observation is motivated by the fact that it takes around 30 seconds to execute on the table (of about 25,000 rows), whereas if I execute:
    SELECT * FROM table WHERE a_text_field LIKE 'pre_processed_string';

where pre_processed_string is the result of the application of replace_something ('%a_given_string%')  it just takes 164ms.

The execution of
    SELECT replace_something ('%a_given_string%')
 takes only 14ms.

Summarizing,
- Replace function:     14ms
- SELECT query without replace function:     164ms
- SELECT query with replace function:      30.000ms

Morever, I cannot create a stored procedure that precalculate the pre_processed_string and executes the query, since I dinamically
compose other conditions in the WHERE clause.

Any suggestion?

Thank you.
--------------060603080809060206020106--