Dmitry Tkach wrote:
>
> BTW, here is a quote from JDBC javadoc:
>
> * An object that represents a precompiled SQL statement.
> * <P>A SQL statement is precompiled and stored in a
> * <code>PreparedStatement</code> object. This object can then be used to
> * efficiently execute this statement multiple times.
>
> I read 'precompiled' as something more than 'parsed for question marks' :-)
> And also note the phrase about being able to 'efficiently execute this
> statement multiple times'...
>
I don't read more into this than simply parsing question marks. It is
all going to depend on the capabilities of the server. To the extent
the server has additional features that can be leveraged to improve the
performance those should be used. Up until 7.3 of postgres no such
features existed. Now they do and we are exploring how to best take
advantage of them. But it doesn't make sense to use a specific server
feature if it doesn't improve performance in the general case. The
testing I have done so far indicates that using the current
implementation of server side prepared statements doesn't help
performance in the general case and may hinder it. I am reluctant to
make a non-backwardly compatible change in the driver until more data
points come in that there are significant performance improvements
possible without decreasing performance in the general case.
> It seems quite clear to me that it states the intent behind having this
> interface to provide the ability for the users to
> parse a query once and be able to execute it again and again...
> As for the set*() functions, PreparedStatement without them would be of
> very limited use (how often would we need to execute
> *the same exact query* multiple times???), and that's the reason it has
> them, *not* to abstract from the database data representation format...
>
I have many statements that don't take any arguments and that do get
executed multiple times. It all depends on the nature of the application.
thanks,
--Barry
