Re: [GENERAL] 7.3 Prepared statements
От | Barry Lind |
---|---|
Тема | Re: [GENERAL] 7.3 Prepared statements |
Дата | |
Msg-id | 3E15E595.9090602@xythos.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] 7.3 Prepared statements ("Charles H. Woloszynski" <chw@clearmetrix.com>) |
Ответы |
Re: [GENERAL] 7.3 Prepared statements
("Charles H. Woloszynski" <chw@clearmetrix.com>)
|
Список | pgsql-jdbc |
Charles H. Woloszynski wrote: >> 2) The implementation on the server will not allow all current uses of >> JDBC PreparedStatements to work (i.e. prepared statements that do >> multiple sql statements in one call, ususally done to reduce number of >> network roundtrips when needing to issue many sql calls at the same >> time). > > > Do you mean that the driver, in this mode, will disallow various forms > of JDBC prepared statements, or that the stored plan support will not be > supported if the query is of one of these forms? I hope it is the > latter, as that would make porting to the new driver easier and avoid > the re-port to a new driver issue. We use PreparedStatements *for > everything* and it is part of the framework that we use to do it this > way. I think it would make the new driver unusable to us if we could > not use the PreparedStatements for certain, currently legal, SQL. > The implementation in the current driver is such that you need to enable the use of server side prepare on a statement by statement basis (default is not to use it). So you should only enable if for those statements for which it will work. To illustrate the problem here is an example: pstat = conn.prepareStatement("insert into foo values (?); update bar set y = ?;); When run in server prepared mode this will issue the following statements to the server: prepare abc(int, int) as insert into foo values ($1); update bar set y = ($2); which will fail since the prepare statement is ended by the first semicolon. So this would be an example of a JDBC prepared statement that works fine currently but would fail when used with server side prepared statements. >> >> 3) The current implementation on the server will cause a decrease in >> performance if you only use the PreparedStatement once. Since the >> implementation of server side prepared statements requires multiple >> roundtrips to prepare, execute and close, there will be more network >> traffic and thus decreased performance if the JDBC prepared statement >> is only used once. And my experience is that the vast majority of >> JDBC prepared statements are only used once. > > > Is that saying that the performance is reduced with the *new > functionality* more than current PreparedStatement processing, or that > PreparedStatements are in genral, slower? Sounds like the former, and > your observation that prepared statements are mostly used only once is > kinda troublesome. Sounds like this feature will need to be > enabled/disabled in the URL (I think I saw a posting about that from > you), to avoid impacting applications that do not re-use prepared > statements. Our framework allows for re-use, so I am looking forward to > improved performance once we start in earnest the move to 7.3.x. > Yes the former. That is why the use of server side prepared statements is not the default. This can hopefully be addressed by changes in the FE/BE protocol in 7.4 so that there isn't any difference in performance. >> >> 4) This is version one of the functionality. We can learn from it to >> understand how it can be improved for 7.4. > > > I hope we can help get some feedback to you on this. Do you have a > timeline for 7.4 features? > Traditionally the postgres release cycle is 6-12 months and we are about 2 months into it. > Thanks, > > Charlie > thanks, --Barry
В списке pgsql-jdbc по дате отправления:
Следующее
От: Aaron MulderДата:
Сообщение: Re: ClassCastException with LargeObjectAPI and Tomcat Connection