pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedEfficiency Problem
3+ messages / 2 participants
[nested] [flat]
* Efficiency Problem
@ 2013-03-17 11:15 Surfing <onlinesurfing@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: Surfing @ 2013-03-17 11:15 UTC (permalink / raw)
To: pgsql-sql
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.
//
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Efficiency Problem
@ 2013-03-17 11:39 Misa Simic <misa.simic@gmail.com>
2013-03-17 11:43 ` Re: Efficiency Problem Surfing <onlinesurfing@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Misa Simic @ 2013-03-17 11:39 UTC (permalink / raw)
To: Surfing <onlinesurfing@gmail.com>; pgsql-sql
Hi,
1) Is function marked as immutable?
2) if immutable doesnt help... It should be possible execute it first, and
use it in other dynamics things in where...
Cheers,
Misa
Sent from my Windows Phone
------------------------------
From: Surfing
Sent: 17/03/2013 12:16
To: pgsql-sql@postgresql.org
Subject: [SQL] Efficiency Problem
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.
**
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Efficiency Problem
2013-03-17 11:39 Re: Efficiency Problem Misa Simic <misa.simic@gmail.com>
@ 2013-03-17 11:43 ` Surfing <onlinesurfing@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: Surfing @ 2013-03-17 11:43 UTC (permalink / raw)
To: Misa Simic <misa.simic@gmail.com>; +Cc: pgsql-sql
IMMUTABLE solved the problem.
Thank you!
Il 17/03/2013 12.39, Misa Simic ha scritto:
> Hi,
>
> 1) Is function marked as immutable?
>
> 2) if immutable doesnt help... It should be possible execute it first,
> and use it in other dynamics things in where...
>
> Cheers,
>
> Misa
>
> Sent from my Windows Phone
> ------------------------------------------------------------------------
> From: Surfing
> Sent: 17/03/2013 12:16
> To: pgsql-sql@postgresql.org <mailto:pgsql-sql@postgresql.org>
> Subject: [SQL] Efficiency Problem
>
> 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.
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2013-03-17 11:43 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2013-03-17 11:15 Efficiency Problem Surfing <onlinesurfing@gmail.com>
2013-03-17 11:39 Re: Efficiency Problem Misa Simic <misa.simic@gmail.com>
2013-03-17 11:43 ` Surfing <onlinesurfing@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox