Re: [JDBC] Efficient use of ON CONFLICT DO UPDATE with the PostgreSQLJDBC driver
От | Dave Cramer |
---|---|
Тема | Re: [JDBC] Efficient use of ON CONFLICT DO UPDATE with the PostgreSQLJDBC driver |
Дата | |
Msg-id | CADK3HH+VdNcfqLXh35kaKcAFWjZaiR=W2u=MELJzP6kX5SQ8ig@mail.gmail.com обсуждение исходный текст |
Ответ на | [JDBC] Efficient use of ON CONFLICT DO UPDATE with the PostgreSQL JDBC driver (Christopher BROWN <brown@reflexe.fr>) |
Ответы |
Re: [JDBC] Efficient use of ON CONFLICT DO UPDATE with the PostgreSQLJDBC driver
Re: [JDBC] Efficient use of ON CONFLICT DO UPDATE with the PostgreSQLJDBC driver Re: Efficient use of ON CONFLICT DO UPDATE with the PostgreSQLJDBC driver Re: Efficient use of ON CONFLICT DO UPDATE with the PostgreSQLJDBC driver |
Список | pgsql-jdbc |
On 13 January 2017 at 06:01, Christopher BROWN <brown@reflexe.fr> wrote:
Hello,I've at last had an opportunity to use PostgreSQL 9.6 (instead of 9.4) for a project, and have been able to use the ON CONFLICT DO UPDATE clause. As it can involve repeating parameter values (including, as is my case, large binary files), I'm wondering if there's any performance or resource-usage side effects (or workarounds) when doing something like this:INSERT INTO foo (c_uuid, file_data, file_name) VALUES (?, ?, ?)ON CONFLICT (c_uuid) DO UPDATE SET file_data = ?, file_name = ?On the Java side, that means invoking PreparedStatement::setBinaryStream TWICE for the same data. I'm not noticing side effects on localhost (but haven't profiled either). Is this fine, or a potential problem? Is there a better approach?
So to summarize you would like some sort of optimization where we figured out that two of the values were the same in the initial insert and the on conflict and only send it once ?
В списке pgsql-jdbc по дате отправления: