Re: long transfer time for binary data

	Johannes wrote:

> \lo_export 12345 /dev/null is completed in 0.86 seconds.

If it's an 11MB file through a 100Mbits/s network, that's
pretty much the best that can be expected.

I would think the above is the baseline against which
the other methods should be compared.

> I sa my images as large object, which afaik is in practise not
> readable with a binary cursor (we should use the lo_* functions). And of
> course I already use the LargeObjectManager of the postgresql jdbc library.

Sounds good.

> You said, the server has to convert the bytes to hex string before
> sending it over the wire.

Only in certain contexts. SELECT lo_get(oid) is a query that returns
bytea, so if the clients requests results in text format, they will
be transferred as text, and it's the responsibility of the client
to convert them back to bytes (or not, who knows, maybe the
client wants hexadecimal).

But lo_get is an exception, and besides a late addition (9.4 I believe).
Generally, client-side access to large objects functions doesn't
use a client-side SQL query, it's done through the 
"Function Call sub-protocol" described here:
http://www.postgresql.org/docs/current/static/protocol-flow.html#AEN108750
and the result comes back as binary.

Presumably the JDBC LargeObjectManager uses that method.

Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite