Re: Very strange performance decrease when reusing a PreparedStatement
От | Simon Riggs |
---|---|
Тема | Re: Very strange performance decrease when reusing a PreparedStatement |
Дата | |
Msg-id | 1241647194.6109.52.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Very strange performance decrease when reusing a PreparedStatement (Roland Roberts <roland@astrofoto.org>) |
Ответы |
Re: Very strange performance decrease when reusing a PreparedStatement
|
Список | pgsql-jdbc |
On Sun, 2009-05-03 at 15:08 -0400, Roland Roberts wrote: > At least PostgreSQL has the ability to tell the parser to reparse > every time you ask it to prepare the statement. Oracle doesn't. The > solution for Oracle isn't relevant, but the real point here is that > your code may have to become smarter to help out the optimizer. We > reparse on every execution, but can't control Oracle's server-side > cache. PostgreSQL lets you control that with prepareThreshold=0. If > we'd had that option with Oracle, we would have had an easy solution. > I'd say PostgreSQL's implementation for this case is a good one. We have a good feature there, definitely. Although there is still more to be done. Oracle's cursor_sharing features are slightly ahead of Postgres, specifically around the "SIMILAR" option. We talked a few years back about an "Option node" that would select sub-plans at runtime based upon the actual values of the bind variable. Nobody's got around to doing anything with that yet. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support
В списке pgsql-jdbc по дате отправления: