Re: [JDBC] Prepared statement performance...

Barry Lind <barry@xythos.com>

From: Barry Lind <barry@xythos.com>
To: Dmitry Tkach <dmitry@openratings.com>
Cc: Aaron Mulder <ammulder@alumni.princeton.edu>, Dave Cramer <Dave@micro-automation.net>, Peter Kovacs <peter.kovacs@sysdata.siemens.hu>, "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>, "pgsql-jdbc@postgresql.org" <pgsql-jdbc@postgresql.org>
Date: 2002-09-27T19:29:00Z
Lists: pgsql-general

Dmitry Tkach wrote:
> 
> I have to disagree with that too, based on my experience...
> In that application I mentioned in the topic that initiated this 
> discussion, the statement, that I have to execute about 30 million times 
> looks like
> 
> "select * from foo where primary_key=bar"
> 
> What could possibly be simpler than that? :-)
> I was surprised to find out however, that in the end the backend turns 
> out to have *more* time parsing and planning that query then actually 
> executing it :-(
> 

I don't disagree that this is a simple query.  But remember that since 
the implementation of server side prepare is through the sql interface 
with each call to execute this statement you still need to issue the 
following sql statement:  execute <name>(bar);  which will still need to 
invoke the parser.  Using server side prepared statements doesn't 
eliminate all parses.  It isn't true that you can just take the original 
  execute time of a statement and assume that with server side prepared 
statements the total time will be the same as that, it will be more.

Executing something 30million times will certainly make even a little 
improvement for a simple statement like this noticable, but 30million 
executes of the same statement certainly isn't the norm.  And I would 
suggest it is the type of environment where serverside prepared 
statements are the most useful.  I hope you can try the new 
functionality and provide us all with real numbers as to how much it helps.

thanks,
--Barry