Re: binary protocol was Performance problem with timestamps in result sets

How about the actual transport cost difference between text and binary
protocols ? it may not be any big difference though, and many times text
representation can be smaller then a binary protocol.

I have no idea about endianness, but as the clients works fine between
different platforms I would assume that the endian format in the protocol is
fixed (but you should not assume things so maybe I am hanging myself again
here).

I do not think it would give much though to use the binary protocol as Java
is not very good when it comes to converting binary data back to native
values unless it is serialized or you start to mess around with nio buffers,
so in the end I do not think there would be much difference in performance.

Mikael

----- Original Message -----
From: "mikael-aronsson" <mikael-aronsson(at)telia(dot)com>
To: "Dave Cramer" <pg(at)fastcrypt(dot)com>
Sent: Thursday, March 09, 2006 1:38 PM
Subject: Re: [JDBC] binary protocol was Performance problem with timestamps
in result sets

> How about the actual transport cost difference between text and binary
> protocols ? it may not be any big difference though, and many times text
> representation can be smaller then a binary protocol.
>
> I have no idea about endianness, but as the clients works fine between
> different platforms I would assume that the endian format in the protocol
> is fixed (but you should not assume things so maybe I am hanging myself
> again here).
>
> I do not think it would give much though to use the binary protocol as
> Java is not very good when it comes to converting binary data back to
> native values unless it is serialized or you start to mess around with nio
> buffers, so in the end I do not think there would be much difference in
> performance.
>
> Mikael
>
> ----- Original Message -----
> From: "Dave Cramer" <pg(at)fastcrypt(dot)com>
> To: "List" <pgsql-jdbc(at)postgresql(dot)org>
> Sent: Thursday, March 09, 2006 1:11 PM
> Subject: [JDBC] binary protocol was Performance problem with timestamps in
> result sets
>
>
>> As Oliver points out the timestamp is not a 64bit integer, or even a
>> floatingpoint number. It is a textual representation of the timestamp
>> which needs to be parsed. I looked at the parsing and I was unable to
>> see anything that could be significantly optimized.
>>
>> So the option of going to the binary protocol exists. There are a number
>> of challenges with this. As Oliver points out this is an all or nothing
>> proposition. In other words you can't ask for just timestamps to be
>> returned in binary. The entire row comes back as binary. Additionally,
>> there are two possible representations of timestamps in postgresql. One
>> is a 64 bit integer, the other is floating point. Added to this there
>> may be endian issues ( do we know the answer to this question ?)
>>
>> Significant performance improvement exists for dates, times, timestamps,
>> however the advantages for the rest of the types is questionable given
>> the above assertions.
>>
>> Comments ?
>>
>> Dave
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 1: if posting/reading through Usenet, please send an appropriate
>> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>> message can get through to the mailing list cleanly
>