Skip site navigation (1) Skip section navigation (2)

Re: How to boost performance of ilike queries ?

From: Antony Paul <antonypaul24(at)gmail(dot)com>
To: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: Russell Smith <mr-russ(at)pws(dot)com(dot)au>,pgsql-performance(at)postgresql(dot)org
Subject: Re: How to boost performance of ilike queries ?
Date: 2005-01-24 14:14:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
I used PreparedStatements to avoid SQL injection attack and it is the
best way to do in JDBC.

Antony Paul

On Mon, 24 Jan 2005 09:01:49 -0500, Merlin Moncure
<merlin(dot)moncure(at)rcsonline(dot)com> wrote:
> Russell wrote:
> > I am not sure what the effect of it being prepared will be, however
> I've
> > had much success
> > with the method above without the queries being prepared.  Others may
> be
> > able to offer advice
> > about if prepare will effect it.
> > 
> There are two general cases I tend to use prepared queries.  First case
> is when there is an extremely complex plan generation step that you want
> to skip.  IMO, this is fairly rare in the normal course of doing things.
> Second case is when you have a relatively simple query that gets
> executed very, very frequently, such as select a,b,c from t where k.
> Even though the query plan is simple, using a prepared query can shave
> 5-15% off your query time depending on various factors (on a low latency
> network).  If you fire off the statement a lot, this adds up.  Not
> generally worthwhile to go this route if you are executing over a high
> latency network like the internet.
> If your application behavior can benefit from the second case, it can
> probably benefit from using parse/bind as well...use ExecPrepared, etc.
> libpq interface functions.
> The cumulative savings of using ExecPrepared() vs. using vanilla
> PQExec() (for simple queries over a high latency network) can be 50% or
> better.  This is both from client's perspective and in server CPU load
> (especially when data is read from cache).  This is most interesting to
> driver and middleware writers who broker data exchange between the
> application and the data.  The performance minded application developer
> (who can make calls to the connection object) can take advantage of this
> however.
> Merlin
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?

In response to

pgsql-performance by date

Next:From: Merlin MoncureDate: 2005-01-24 15:30:22
Subject: Re: [SQL] OFFSET impact on Performance???
Previous:From: Merlin MoncureDate: 2005-01-24 14:01:49
Subject: Re: How to boost performance of ilike queries ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group