Re: [postgis-devel] JDBC & WKB - 400% overhead - Mailing list pgsql-jdbc

From Kris Jurka
Subject Re: [postgis-devel] JDBC & WKB - 400% overhead
Date
Msg-id Pine.BSO.4.56.0502231405360.11888@leary.csoft.net
Whole thread Raw
In response to Re: [postgis-devel] JDBC & WKB - 400% overhead  (Markus Schaber <schabios@logi-track.com>)
Responses Re: [postgis-devel] JDBC & WKB - 400% overhead  (Markus Schaber <schabios@logi-track.com>)
List pgsql-jdbc

On Wed, 23 Feb 2005, Markus Schaber wrote:

> > ResultSet rs2 = st.executeQuery("select 5::float8,asBinary('POINT(0 0)')");
> > rs2.next();
> > byte[] bs = rs2.getBytes(2);
> > assertTrue(bs.length == 21);
> >
> > The WKB representation of a 'POINT(0 0)' is 21 bytes long (1 byte for
> > xdr/ndr flag, 4 bytes for type, and 2 8-byte doubles = 21 bytes).
> >
> > It clearly receives 84 bytes of data from the server.  This is the bytea
> > text representation:
> > \001\001\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000
> >
> > The ResultSet#getBytes() function converts this to a byte[].
>
> Maybe your postgresql driver only uses text transfer up to now.
> asBinary() returns a byte array, so this should be transferred more
> efficiently.
>

The driver receives all data as text.  To be able to receive binary data
we must support binary data for all types because we do not know what type
we will be getting back from the SELECT before it is run.  Getting that
information would require an extra network round trip so we don't want to
do that.  Doing all binary transfer is on the 8.1 todo list, but I've yet
to really get started on it.

Kris Jurka


pgsql-jdbc by date:

Previous
From: Kris Jurka
Date:
Subject: Re: PGStatement#setUseServerPrepare breaking
Next
From: Kris Jurka
Date:
Subject: Re: DatabaseMetaData.getIndexInfo and function-based indexes