Re: Re: JDBC Performance
От | Peter Mount |
---|---|
Тема | Re: Re: JDBC Performance |
Дата | |
Msg-id | Pine.LNX.4.21.0010031158450.420-100000@maidast.demon.co.uk обсуждение исходный текст |
Ответ на | Re: Re: JDBC Performance (Gunnar R|nning <gunnar@candleweb.no>) |
Список | pgsql-general |
On 2 Oct 2000, Gunnar R|nning wrote: > Peter Mount <peter@retep.org.uk> writes: > > > > > For JDBC2, I'm planning (may get done for 7.1) an alternate ResultSet > > class that uses cursors. This would speed things up as the entire > > resultset isn't received in one go. That's the biggest bottleneck of them > > all. > > > > I would think this depends on the queries you execute. Is it any overhead on > the backend side related to retrieving results through the use of > cursors(ignoring the extra bytes sent) ? Which is why it's an alternate class, not a replacement. The existing one is for general use, but you can define the cursor name, so if you do for a particular Statement object, then the ResultSet's from it would use that cursor. > If you only use a fragment of the data in the result set this method would > of course be faster, but in other situations I'm concerned that you will > only add overhead to the ResulSet.next() method(with familiy). But you > mentioned alternate implementation, so that would probably mean that the > user can choose the appropriate implementation for his application ? Yes. The related methods are: Statement.setCursorName(String name) Statement.setFetchDirection(int direction) Statement.setFetchSize(int rows) The Statement.getResultSetType() method returns TYPE_FORWARD_ONLY for the existing class, and TYPE_SCROLL_INSENSITIVE for the new one. Peter -- Peter T Mount peter@retep.org.uk http://www.retep.org.uk PostgreSQL JDBC Driver http://www.retep.org.uk/postgres/ Java PDF Generator http://www.retep.org.uk/pdf/
В списке pgsql-general по дате отправления: