Re: BLOB performance test FYI
От | Barry Lind |
---|---|
Тема | Re: BLOB performance test FYI |
Дата | |
Msg-id | 3CC05FBF.2050907@xythos.com обсуждение исходный текст |
Ответ на | Re: BLOB performance test FYI ("Joe Shevland" <jshevland@j-elite.com>) |
Список | pgsql-jdbc |
It may be possible to stream the responces but certainly is difficult. Consider the following code: PreparedStatement l_stat = l_conn.PrepareStatement("select a,b from foo"); ResultSet l_rset = l_stat.executeQuery(); while (l_rset.next()) { PreparedStatement l_stat2 = l_conn.prepareStatement("select y, z from bar where y = ?"); l_stat2.setInt(1, l_rset.getInt(1)); ResultSet l_rset2 = l_stat2.executeQuery(); while l_rset2.next() { //do something useful } } If the first first query doesn't fetch all of the data the second nested query can't use the socket to get its data. So to do this you would need to code the driver to pull all of the data into memory when the socket was needed by some other query. --Barry Anders Bengtsson wrote: > On 2002-04-18 Barry Lind wrote: > > >>This is a great idea. This would certainly solve the memory problem for >>inserts. Selects on the other hand wouldn't be helped since you need to >>read the entire value first before you can get to the rest of the values. > > > (my second reply to the same message) > > I just found this in the JDBC specification: > > "For maximum portability, columns within a row should be read in > left-to-right order, and each column should only be read once. This > reflects implementation limitations in some underlying database > protocols." > > This means that it would be possible to stream responses too, even with > the current protocol. But it's very impractical for the user, so it's > not a very good solution. >
В списке pgsql-jdbc по дате отправления: