Re: bytea size limit?

Michael Privat wrote:
> With regards to individually escaping, it's just as expensive as how
> it was before, except that it doesn't make several copies of the array
> like it used to (hence the memory saving). I don't think there is any
> performance impact at all. Basically just a memory gain.

Doesn't it end up creating an individual String (and backing char[]) for
each source byte? While these objects are very short-lived, they are
extra garbage and will cause more frequent GCs.

> As far as the encoding. I think in your original email you had
> mentioned that the driver used UTF-8 (in which case there is an
> obvious optimization that can be made), but I couldn't find it in the
> driver. Everything looked like it was inheriting from the encoding
> scheme set in the connection.

Everything does indeed use the encoding object on the connection. The
trick is that if you look at the V3 connection setup code, the encoding
is always set to UNICODE which maps to Java's UTF8.

V2 connections can have a variety of encodings. The driver sets the
encoding to UNICODE for server versions >= 7.3, but uses the database's
encoding for earlier versions. But we don't need to know the encoded
length in advance when talking V2 anyway..

-O