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

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 (view raw or flat)
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

pgsql-jdbc by date

Next:From: Radosław SmoguraDate: 2010-10-08 09:12:37
Subject: Re: The logic behind the prepared statement in PostgreSQL
Previous:From: danapDate: 2010-10-08 01:16:53
Subject: DatabaseMetaData.getTablePrivileges()

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