Re: Does preparing statements other than selects help performance?

David Goodenough wrote:
> On Friday 05 August 2005 11:57, Martijn van Oosterhout wrote:
>
>>On Fri, Aug 05, 2005 at 10:08:42AM +0100, David Goodenough wrote:
>>
>>>I was looking at an application recently which was written in Java and
>>>used Postgresql as it DB. In it extensive use had been made of
>>>PreparedStatements both for SELECTs and for INSERT, UPDATE and DELETE
>>>statements. Some of the routines had multiple UPDATEs doing much the
>>>same thing but with slightly different parameters. In the comments it
>>>was stated that it was better to prepare lots of statements in advance
>>>rather than build one on the spot (and then prepare it, it needed the
>>>substitution) because of the optimiser.
>>
>>Which version of PostgreSQL was this built for? Until recently there
>>was no support for server side prepared statements so it mattered not
>>one wit whether you had one or a thousand prepared queries, it was all
>>done by the client anyway.
>
> I am not sure it was originally build for PostgreSQL, but it all client side
> anyway, or that its inside Tomcat and thus from PG's point of view
> client side. I presume by server side you mean triggers and functions or
> am I misunderstanding you?
>

He's saying that until recently, PostgreSQL did not support prepared
queries. That feature was introduced in version 7.3 (I guess that's not
very recent, but it can take a while for client code to start using the
new features).

So, it's possible that the "prepared queries" you're using are actually
just sending a new query each time. For instance, if you connect to a
7.2 database and start doing prepared queries, surely those are done on
the client side, because the 7.2 server doesn't support prepared queries.

Regards,
Jeff Davis