Stephen>I encourage you to look through the archives
The thing is pl/pgsql suffers from exactly the same problem.
pl/pgsql is not a typical language of choice (e.g. see Tiobe index and alike), so the probability of running into "prepared statement issues" was low.
As more languages would use server-prepared statements, the rate of the issues would naturally increase.
JFYI: I did participate in those conversations, so I do not get which particular point are you asking for me to "look through" there.
Stephen Frost:
And is the source of frequent complaints on various mailing lists along
the lines of "why did my query suddently get slow the 6th time it was
run?!".
I claim the following:
1) People run into such problems with pl/pgsql as well. pl/pgsql does exactly the same server-prepared logic. So what? Pl/pgsql does have a query cache, but other languages are forbidden from having one?
2) Those problematic queries are not that often
3) "suddently get slow the 6th time" is a PostgreSQL bug that both fails to estimate cardinality properly, and it does not provide administrator a way to disable the feature (generic vs specific plan).
4) Do you have better solution? Of course, the planner is not perfect. Of course it will have issues with wrong cardinality estimations. So what? Should we completely abandon the optimizer?
I do not think so.
Query cache does have very good results for the overall web page times, and problems like "6th execution" are not that often.
By the way, other common problems are:
"cached plan cannot change result type" -- PostgreSQL just fails to execute the server-prepared statement if a table was altered.
"prepared statement does not exist" -- the applications might use "deallocate all" for some unknown reason, so the driver has to keep eye on that.
"set search_path" vs "prepared statement" -- the prepared statement binds by oids, so "search_path changes" should be accompanied by "deallocate all" or alike.
Vladimir