Re: bytea performance tweak - Mailing list pgsql-jdbc

From Andreas Schmitz
Subject Re: bytea performance tweak
Date
Msg-id 20110627234957.GA2653@summalogicae.occamlabs.local
Whole thread Raw
In response to Re: bytea performance tweak  (Maciek Sakrejda <msakrejda@truviso.com>)
List pgsql-jdbc
Maciek Sakrejda wrote:

Hi,

> >> Is there a timeline for fully supporting the binary protocol?
> >
> > A PostgreSQL installation can contain user-defined types with a custom
> > binary format, so this will not work with all databases anyway.
>
> Having to read unknown types in text mode is not any easier if you're
> going to do something interesting with them. In either case, the
> protocol provides a way to read the type payload off the wire (so,
> e.g., a column with a type you can't read won't "mess up" the whole
> result set), but it's up to you to process those bytes. As Vitalii
> stated, something like PGObject is probably the right way to handle
> this.
>
> > A way to tell PostgreSQL to always send some [types] in binary format
> > would solve this, though.
>
> (I assume you meant "types" not "times")
>
> Yep, that would be nice. There are per-*column* output facilities in
> the protocol, but not per-type. It's possible to ask the server for
> the columns in a query before you commit to output types, but that
> involves an extra round trip which won't be worth it most of the time
> (still, it could be worth it if you're doing something that outputs a
> lot of rows with far leaner binary representations for some data
> types). Perhaps per-statement encoding choice might be the right
> compromise, although that smells like a niche use case.
>
> What's the current state of the binary patch? The wiki (
> http://wiki.postgresql.org/wiki/JDBC-BinaryTransfer ) doesn't say.
> With a brief look at the list archives, the last activity I see is a
> completely new patch submitted by Radosław Smogura, but that
> discussion peters out. That discussion implies we want a solution to
> the "which-types-to-encode-how" problem, but realistically, if we want
> that, we won't have binary support until the protocol changes to allow
> per-type encoding selection. Would a polished patch with
> all-or-nothing connection-flag-level binary support be acceptable?

so it seems to me that switching to the binary protocol is probably
going to be hard, without server side support. What about just applying
my patch in the meantime, including Oliver's fix of course?

Best regards, Andreas

Attachment

pgsql-jdbc by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Connecting over UNIX domain sockets
Next
From: Altaf Malik
Date:
Subject: Re: installing postgresql jdbc driver in Mac OS X Lion