[postgis-devel] JDBC & WKB - 400% overhead

[dblasby at openplans.org]

>Sad. But at least, we can be shure that it is a bytea specific problem
>and not a PostGIS specific problem.
>

Well - if you look at the ResultSet#getBytes() code, it explicity
decodes the "\000" format for columns of type bytea.

Perhaps using a Base64 encoding would be a good idea - its almost 3* as
efficient as this encoding (ie. 4 transfer bytes gives you 3 bytes of
actual data).

So, this is, fundamentally, a bytea problem.  Its really a SQL spec
problem since this is the defined behaviour for bytea transit - its
unlikely the case that Postgresql folks will change it.

But, its a postgis problem because its using bytea as the
representation.

Has anyone looked at just returning straight binary?  Postgresql
[usually] does not use cstrings (null terminated) - it uses pascal-like
strings (first 4 bytes are length, followed by byte data).  If you look
at the transit code, if you just write out straight binary, it should
be able to handle it.  Of course, you will no longer be able to use it
interactively because programs like psql will expect the output to be
cstrings.

dave




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/