> > Right now, I'm transitioning to ExexPrepared to skip the string escaping > > step on the client side. I would hate to lose that ability. ExecParams > > is a little more work to set up (doable, though). > > OTOH, if you're taking client code queries and replacing them with > EXECUTEs (which I sort of gathered some people were doing), all it should > really do is move the matching activity to the server...
There is one subtle difference, and that the type resolution gets moved from the server to the client. ExecParams() requires a list of type OIDs to be sent along with the statement whereas ExecPrepared() does not. To me, this is an inconsistent interface is set up with the parameter name, not the oid of the parameter. To me, it makes much more sense to resolve by type name in all cases, but this may have some performance implications. > But why should anyone insist on a "transaction agnostic scenario" yet > play with prepared statements? That seems backwards to me. Transactions Because it improved statement turnaround by about 33%, and that's all I really care about. The conceptual case seems outweighed by practical matters (if you move to a transactional lifetime first, that is). This performance difference is like having an extra processor. > In any case, AFAICS my proposal does away with the need to wrap anything, > or keep track of transactions and/or prepared statements. Would it work > for you? Yes, it would. It would actually make my life a lot easier (notwithstanding my minor gripe with ExecParams) because I would no longer have to deal with all the complexities surrounding prepared statements. This is A Good Thing, because the optimization is generic and thus will benefit a lot more people. It is also more a more complex optimization model; and I think you would have to justifiably prove that it is in the same performance league as the current prepared statement model. Also the current prepared statement behavior should be retained for 7.5 and perhaps deprecated if your viewpoint wins out (and it should). Merlin ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org