Stephen> While it may have good results in many cases, it's not accurate to say that using prepared statements will always be faster than not.
There's no silver bullet. <-- that is accurate, but it is useless for end-user applications I've never claimed that "server prepared statement" is a silver bullet. I just claim that "PrepareBindExecuteDeallocate" message does have justification from performance point of view. Stephen Frost> Dropping and recreating the prepared statement is how that particular issue is addressed. Stephen, The original problem is: "extended query execution is slow" I recommend "let's just add a query cache" You mention: "that does not work since one query in a year might get slower on 6th execution" I ask: "what should be done _instead_ of a query cache?" You say: "the same query cache, but execute 5 times at most" Does that mean you agree that "query cache is a way to go"? I do not follow that. Of course, I could add "yet another debugger switch" to pgjdbc so it executes server-prepared statements 5 times maximum, however I do consider it to be a PostgreSQL's issue. I do not like to hard-code "5" into the driver logic. I do not like making "5 times maximum" a default mode. Vladimir
