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 по дате отправления:

Предыдущее
От: Barry Lind
Дата:
Сообщение: Re: [PATCHES] patch for ResultSet.java
Следующее
От: Barry Lind
Дата:
Сообщение: Re: BLOB performance test FYI