Re: The logic behind the prepared statement in PostgreSQL

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

In response to

Browse pgsql-jdbc by date

  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()