Re: bytea performance tweak
От | Maciek Sakrejda |
---|---|
Тема | Re: bytea performance tweak |
Дата | |
Msg-id | BANLkTiki7we3y+jph9AUeiZwHpqiTyMx8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: bytea performance tweak (Florian Weimer <fweimer@bfk.de>) |
Ответы |
Re: bytea performance tweak
|
Список | pgsql-jdbc |
>> 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? --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 (650) 242-3500 Main www.truviso.com
В списке pgsql-jdbc по дате отправления: