| From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
|---|---|
| To: | Dave Cramer <pg(at)fastcrypt(dot)com>, Christopher BROWN <brown(at)reflexe(dot)fr> |
| Cc: | List <pgsql-jdbc(at)postgresql(dot)org> |
| Subject: | Re: Efficient use of ON CONFLICT DO UPDATE with the PostgreSQL JDBC driver |
| Date: | 2017-01-13 14:42:18 |
| Message-ID: | CAB=Je-GOicmnV00aToC1Gvt4GMZBwj2psLO5AnQamK4b=-c1hA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-jdbc |
>On the Java side, that means invoking PreparedStatement::setBinaryStream
TWICE for the same data.
AFAIK, frontend-backend protocol allows to reuse $1 multiple times in the
same query, so it seems to be indeed a bit efficient to use
values($1, $2, $3) on conflict.... set file_data=$1, file_name=$2
kind of query.
Obviously, you can use pl/pgsql procedure to workaround that. At least that
would optimize network traffic.
AFAIK, JDBC references parameters by parameter position, so there's no
implementation-independent way to reuse the same parameter without it
sending it twice over the wire.
Vladimir
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher BROWN | 2017-01-13 14:52:44 | Re: Efficient use of ON CONFLICT DO UPDATE with the PostgreSQL JDBC driver |
| Previous Message | Dave Cramer | 2017-01-13 14:20:09 | Re: Efficient use of ON CONFLICT DO UPDATE with the PostgreSQL JDBC driver |