Re: Change of format of returned flat value after prepareThreshold
От | Dave Cramer |
---|---|
Тема | Re: Change of format of returned flat value after prepareThreshold |
Дата | |
Msg-id | CADK3HH+Pi0idaeA6vfiN5ep80y99bAq9wuprDamKFPxU4QazCw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Change of format of returned flat value after prepareThreshold (Mikko Tiihonen <Mikko.Tiihonen@nitorcreations.com>) |
Ответы |
Re: Change of format of returned flat value after prepareThreshold
|
Список | pgsql-jdbc |
Sorry to hijack the thread; I'm wondering what it would take to enable more binary transfers. I played around with arrays, and that doesn't seem too onerous ?
On 19 October 2015 at 08:30, Mikko Tiihonen <Mikko.Tiihonen@nitorcreations.com> wrote:
> > but this jdbc driver feature is
> >supposed to be more of a debug feature, because it slows down queries due to needing an extra
> >round-trip for each query.
>
> Mikko, binary transfer should not be considered a "debug" feature.
I know. I wrote the original jdbc driver binary transfer code because I wanted better performance.
But you clipped half of my sentence it stars with:
"An alternative is to request binary transfers from the first query" - meaning that the debug feature
is the performance killer that requests binary transfers for also the first query by doing a backend
round-trip to describe what kind of in/out parameters the operation contains - before executing the
actual statement.
It is currently used by jdbc driver unit test framework so that every operation need not be tried n
times in unit tests to verify that the binary transfers work for all operations.
-Mikko
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
В списке pgsql-jdbc по дате отправления: