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