Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / General DB Topics / General DB Topics / June 2004

Tip: Looking for answers? Try searching our database.

Parameterized queries running slower than nonparamaterized queries

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
gary b - 25 Jun 2004 23:44 GMT
Hello

When I use a PreparedStatement (in jdbc) with the following query:

SELECT  store_groups_id
FROM store_groups
WHERE store_groups_id IS NOT NULL  
AND type = ?
ORDER BY group_name

It takes a significantly longer time to run (the time it takes for
executeQuery() to return ) than if I use

SELECT  store_groups_id
FROM store_groups
WHERE store_groups_id IS NOT NULL  
AND type = 'M'
ORDER BY group_name

After tracing the problem down, it appears that this is not precisely
a java issue, but rather has to do with the underlying cost of running
parameterized queries.

When I open up MS Enterprise Manager and type the same query in - it
also takes far longer for the parameterized query to run when I use
the version of the query with bind (?) parameters.

This only happens when the table in question is large - I am seeing
this behaviour for a table with > 1,000,000 records. It doesn't make
sense to me why a parameterized query would run SLOWER than a
completely ad-hoc query when it is supposed to be more efficient.

Furthermore, if one were to say that the reason for this behaviour is
that the query is first getting compliled and then the parameters are
getting sent over - thus resulting in a longer percieved execution
time - I would respond that if this were the case then A) it shouldn't
be any different if it were run against a large or small table B) this
performance hit should only be experienced the first time that the
query is run C) the performance hit should only be 2x the time for the
non-parameterized query takes to run - the difference in response time
is more like 4-10 times the time it takes for the non parameterized
version to run!!!

Is this a sql-server specific problem or something that would pertain
to other databases as well? I there something about the coorect use of
bind parameters that I overall don't understand?

If I can provide some hints in Java then this would be great..
otherwise, do I need to turn/off certain settings on the database
itself?

If nothing else works, I will have to either find or write a wrapper
around the Statement object that acts like a prepared statement but in
reality sends regular Statement objects to the JDBC driver. I would
then put some inteligence in the database layer for deciding whether
to use this special -hack- object or a regular prepared statement
depending on the expected overhead. (Obviously this logic would only
be written in once place.. etc.. IoC.. ) HOWEVER, I would desperately
want to avoid doing this.

Please help :)
Daniel Dittmar - 25 Jun 2004 23:57 GMT
> Hello
>
[quoted text clipped - 14 lines]
> AND type = 'M'
> ORDER BY group_name

Try to compare the execution plans for both versions. With the values
filled in, the optimizer has more information to work with and might
choose a different execution plan.

Daniel
Nick Landsberg - 26 Jun 2004 00:58 GMT
> Hello
>
[quoted text clipped - 42 lines]
> to other databases as well? I there something about the coorect use of
> bind parameters that I overall don't understand?

I have one data point from another DBMS (Times10) -

Prepared queries (individual selects, updates, deletes, etc.)
were benchmarked are roughly 5-10 times *faster* than
direct queries.  (300-500 microseconds of CPU vs. 3-5
milliseconds of CPU.  Sun, Solaris, 900 Mhz., JDBC,
no disk I/O's since Times10 is an in-memory DBMS.)

We did not do "order by" since we normally
use the database for transactions only.

> If I can provide some hints in Java then this would be great..
> otherwise, do I need to turn/off certain settings on the database
> itself?

I would avoid the below hack at all costs.  Given that
other databases perform better with prepared queries
I would pursue finding out what settings, etc. you need
to twiddle.

> If nothing else works, I will have to either find or write a wrapper
> around the Statement object that acts like a prepared statement but in
[quoted text clipped - 6 lines]
>
> Please help :)

Signature

"It is impossible to make anything foolproof
because fools are so ingenious"
 - A. Bloch

AK - 26 Jun 2004 15:27 GMT
this is absolutely normal for every RDBMS and it makes perfect sence.
A paramaterized query uses 'one size fits all' approach. Once the plan
is prepared, it is always used no matter whatever values fot he
parameters are.
However, for some queries, different execution plans are optimal,
depending on parameter values. For instance, try range queries (make
sure the index is not clustered) or consider the case of data skew (if
MS SQL is able to recognize data skew).
So, some (not many) queries are better be left dynamic, every
experienced database professional knows that.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.