Обсуждение: ResultSet.getBinaryStream nothing more than a ResultSet.getBytes() call?

I've been working to minimize the memory footprint of my application.
I was under the impression that ResultSet.getBinaryStream would be more
efficient than getBytes().  Certainly the documented semantics imply
that that is a goal (since you must process the InputStream from
getBinaryStream before the call to ResultSet.next() or even processing
the next column.

But the following trace from a java heap profile suggests
that we're still just copying the bytes from the resultset as with
getBytes() instead
of streaming the ones already in memory, though perhaps it's because
I'm using a read(buf) call on the stream.

Anybody got an authoritative answer?  Or if you point me at a 8.0DEV
driver tarball I'll look myself, but I don't run CVS and couldn't find a
tarball on gborg.

TRACE 18107:
org.postgresql.util.PGbytea.toBytes(PGbytea.java:29)
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBytes(AbstractJdbc2ResultSet.java:1986)
org.postgresql.jdbc2.AbstractJdbc2ResultSet.getBinaryStream(AbstractJdbc2ResultSet.java:2115)
org.apache.commons.dbcp.DelegatingResultSet.getBinaryStream(DelegatingResultSet.java:221)

Thanks...

Jeffrey Tenny wrote:
> I've been working to minimize the memory footprint of my application.
> I was under the impression that ResultSet.getBinaryStream would be more
> efficient than getBytes().  Certainly the documented semantics imply
> that that is a goal (since you must process the InputStream from
> getBinaryStream before the call to ResultSet.next() or even processing
> the next column.
>
> But the following trace from a java heap profile suggests
> that we're still just copying the bytes from the resultset as with
> getBytes() instead
> of streaming the ones already in memory, though perhaps it's because
> I'm using a read(buf) call on the stream.

The intermediate copy happens because the "in memory" version is a
text-escaped representation of the bytea value, not just a straight
bytearray.

getBinaryStream() could indeed be smarter, avoiding the intermediate
bytearray by decoding the text representation on demand. But noone has
implemented this yet.

Probably a better long-term solution is to move to binary-format results
at the protocol level. That's somewhere on my todo list, but I'm not
making much progress on it at the moment.

-O