Am 23.01.2016 um 01:25 schrieb Daniel Verite: > Johannes wrote: > >> psql >> select lo_get(12345); >> +ssl -compression 6.0 sec >> -ssl 4.4 sec > > psql requests results in text format so that SELECT does not > really test the transfer of binary data. > With bytea_output to 'hex', contents are inflated by 2x. > > Can you tell how fast this goes for you, as a comparison point: > \lo_export 12345 /dev/null > ? > > Many client interfaces use the text format, but you want to > avoid that if possible with large bytea contents. > In addition to putting twice the data on the wire, the server has to > convert the bytes to hex and the client has to do the reverse operation, > a complete waste of CPU time on both ends. > > At the SQL level, the DECLARE name BINARY CURSOR FOR query > can help to force results in binary, but as the doc says: > > http://www.postgresql.org/docs/current/static/sql-declare.html > > "Binary cursors should be used carefully. Many applications, including > psql, are not prepared to handle binary cursors and expect data to > come back in the text format." > > Personally I don't have experience with JDBC, but looking at the doc: > https://jdbc.postgresql.org/documentation/94/binary-data.html > > I see this: > > "To use the Large Object functionality you can use either the > LargeObject class provided by the PostgreSQL™ JDBC driver, or by using > the getBLOB() and setBLOB() methods." > > If the data lives on the server as large objects, I would think that > this LargeObject class has the best potential for retrieving them > efficiently, as opposed to "SELECT lo_get(oid)" which looks like > it could trigger the undesirable round-trip to the text format. > You may want to test that or bring it up as a question to JDBC folks. > > > Best regards, \lo_export 12345 /dev/null is completed in 0.86 seconds. I save 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. You said, the server has to convert the bytes to hex string before sending it over the wire. In my understanding bytea values are stored as strings and are may compressed in TOAST storage. > The bytea data type allows storage of binary strings [1] What is correct? Your post gave me the hint. I found a binary transfer parameter in the postgresql jdbc library available [2], [3]. But turning it on, doesn't speed anything up. It seems the binary transfer mode is active by default. The byte counter (iptables -v) is nearly as big as the image itself. It is already optimal. packets byte counter psql +ssl 8514 23M psql -ssl 8179 23M pgadmin -ssl 11716 33M pgadmin +ssl -compress 12196 34M pgadmin +ssl +compress 12193 34M java jdbc +ssl 14037 24M java jdbc -ssl 5622 12M (3.1 seconds) java jdbc -ssl binarytransfer=true 5615 12M (3.1 seconds) In fact I do not understand what is the bottleneck. OK my server, runs in a Raspberry 2b+, thats maybe not the best hardware. But the scp command could be finished from there in 1.3 seconds. So the bottleneck is not the network speed. And also not the USB diskdrive. Maybe it is the slow java program? I pointed my java program to my local postgresql instance (with the same image as large object, same mtu, no loopback device, no unix socket, but better system) it was finished in 400 ms. The java progam is out too. Did I forget anything? I'm afraid I have to live with it and may use thumbnail images. Best regards [1] http://www.postgresql.org/docs/current/static/datatype-binary.html [2] https://wiki.postgresql.org/wiki/JDBC-BinaryTransfer [3] https://jdbc.postgresql.org/documentation/94/connect.html#connection-parameters
Attachment:
signature.asc
Description: OpenPGP digital signature
