Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Databases / August 2007

Tip: Looking for answers? Try searching our database.

jdbc and prepared statement compilation

Thread view: 
igor.berman@gmail.com - 24 Jul 2007 09:39 GMT
Hi,
I have severe performance problem with compilation of sql-queries. So
I wanted to ask, if there is another better way to create our queries
to avoid many compilations:
I must to notice that I DO use PreparedStatement.

small example:
say I have table(key - primary key, field1, field2)
1. Select * from table where key = ?
2. Select * from table where key = ? or key = ?
3. Select * from table where key = ? or key = ? or key = ?(another way
to write this is
select * from table where key in (?, ?, ?)
Number of key-options supplied by user and user can choose for what
keys select should be executed.
Every key is not logically-connected to another by any other field,
i.e. I can't rewrite query to something like: select * from table
where field1 = ?

So my statement-cache thinks that all three queries are different,
since the texts of queries are different, so in three cases I got
query-compilation in data-base...

My solution-try was to create query with fixed number of options for
example:
select * from table where key = ? or key = ? or key = ?
and if user supplies less then 3 keys I'll duplicate last key and if
user supplies more than 3 keys I'll prepare statement once and each
time execute with 3 key-options and at the end collecting all results
for user.

My question is : is there another way to write such
queries(dynamically changing number of option in key predicate) such
that I'll get cache-hit?
Lew - 24 Jul 2007 13:33 GMT
...
> 1. Select * from table where key = ?
> 2. Select * from table where key = ? or key = ?
[quoted text clipped - 10 lines]
> since the texts of queries are different, so in three cases I got
> query-compilation in data-base...
...
> My question is : is there another way to write such
> queries(dynamically changing number of option in key predicate) such
> that I'll get cache-hit?

No.

Prepared statements only re-use statements that are the same, that is in part,
that have the same number of substitution parameters.  Each of those three
patterns you present would prepare separately.

That is because they are three completely different statements.  They are not
equivalent to the planner.

Signature

Lew

igor.berman@gmail.com - 24 Jul 2007 20:24 GMT
> No.
>
[quoted text clipped - 4 lines]
> That is because they are three completely different statements.  They are not
> equivalent to the planner.

Ok, I've understood this already, that those 3 are different, my main
question is: is there some smart technique to handle above problem
Even though 3 are different, I still want to make number of
compilation as less as possible, since it's very cpu-consuming
process...
Thanks in advance.
Frank Langelage - 24 Jul 2007 21:53 GMT
>> No.
>>
[quoted text clipped - 11 lines]
> process...
> Thanks in advance.

You said, you already use PreparedStatements. How do you?
If the number of key values is in a limited range, you might use a
Hashmap<Integer,PreparedStatement> or something like this to cache the
PreparedStatements.
The key for th Hashmap is the number of key values for the statement.
So you'll prepare a statement once for each number of key values and
reuse it from then.
GArlingtonUK - 08 Aug 2007 16:56 GMT
> > No.
>
[quoted text clipped - 11 lines]
> process...
> Thanks in advance.

Try using Stored Procedure...


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
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



©2008 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.