From: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Cc: | louis <louis(at)ibms(dot)sinica(dot)edu(dot)tw>, Oliver Jowett <oliver(at)opencloud(dot)com> |
Subject: | Re: The logic behind the prepared statement in PostgreSQL |
Date: | 2010-10-08 09:10:16 |
Message-ID: | 201010081110.16571.rsmogura@softperience.eu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Hi,
> I think it's because postgresql JDBC Driver has a default limit for the max
> number of preparedStatement, which is 4. Can anyone tell me where to
> adjuest this parameter?
This parameter 4 is associated with prepare threshold. It says how many times
the given prepared statement (as Java object) will be executed before it will
be compiled into true, server side prepared statement.
In many applications developers uses PreparedStatement class just to wrap
parameters, so compiling such statement in server side statement adds unneeded
overhead. After you execute such PS few times then it's compiled, and in logs
you will see EXECUTE S_1 or S_1/C_1.
PG JDBC driver doesn't have built in support for caching statements in any
way, so two statements with same SQL will be mapped to different statements in
database, even if that are called in scope of same connection.
If you would like to cache statements, currently most servers support this, by
wrapping original database objects.
Kind ragards,
Radosław Smogura
http://www.softperience.eu
From | Date | Subject | |
---|---|---|---|
Next Message | Radosław Smogura | 2010-10-08 09:12:37 | Re: The logic behind the prepared statement in PostgreSQL |
Previous Message | danap | 2010-10-08 01:16:53 | DatabaseMetaData.getTablePrivileges() |