Re: PostgreSQL gaps wrt to java, and jdbc

No, unfortunately not, as there is a big difference between compression and binary transmission. See the following example:

<Some-Element xyz="345678,901">

<Some-Other-Element abc="54321,876">

<Some-Value my-attribute="123456,789"/>

</Some-Other-Element>

</Some-Element>

With compression, you can certainly get rid of the whitespace, and if the compression algorithms is better you even will have refs instead of element names, but that's it, mostly. What about the numbers? Still transfered untouched, as unique hence uncompressable. So lots of integers and decimals screws compression.

Binary transmission on the other hand will only need four bytes per integer. That makes twelve bytes for all the above attributes.

To sum up, compressed transmission should be an option that is performed on a lower level (like gzip transmission with http), but is *additive* to binary transmission. The latter should be used even in case no compressed transmission is in place at all.

-Markus

From: davecramer(at)gmail(dot)com [mailto:davecramer(at)gmail(dot)com] On Behalf Of Dave Cramer
Sent: Dienstag, 7. Juli 2015 19:54
To: Markus KARG
Cc: List
Subject: Re: [JDBC] PostgreSQL gaps wrt to java, and jdbc

Looking at the backend code. One possibility is to just use compression to send it over?

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 6 July 2015 at 12:35, Markus KARG <markus(at)headcrashing(dot)eu> wrote:

Binary represenation of XML and JSON instead of converting it to a String BEFORE transmission. Both JSON and XML essentially are graphs, and can be inflated with whitespace on the driver side AFTER transmission. Same in the other direction (deflate by transmitting binary object graph instead of whitespace-inflated String representation).

From: pgsql-jdbc-owner(at)postgresql(dot)org [mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Dave Cramer
Sent: Montag, 6. Juli 2015 14:15
To: List
Subject: [JDBC] PostgreSQL gaps wrt to java, and jdbc

I have been actively maintaining the driver off and on since 1999 or so. Recently we have had a flurry of activity and one of the things I noticed was the surprise that PostgreSQL didn't support X or did Y in some unexpected way. Sometimes we are a bit too complacent, and accept things the way they are.

I am wondering what could the server do better that would help JDBC?

Obviously streaming a column is one. Possibly rowid's. Anything else ?

Dave Cramer