From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Adding support for batches that return generated keys |
Date: | 2014-10-10 09:02:51 |
Message-ID: | 5437A0BB.4070303@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Hi all
I've implemented support for batches that return generated keys.
https://github.com/pgjdbc/pgjdbc/pull/204
and I'm looking for feedback before I merge this into master.
Currently the driver internally executes these one-by-one, which is
pretty horrible if there's a big round-trip involved.
Details in Github issue #195:
https://github.com/pgjdbc/pgjdbc/issues/195
With this change PgJDBC now executes batches that return generated keys
in internal sub-batches separated by periodic Sync, flush, and input
consume pauses, just, like it does for batches that don't return keys.
This is safe (or almost as safe as it ever was given github #194)
because we force a Describe, then estimate the result row size and
adjust the batch size accordingly.
This approach does increase the deadlock risk if a batch executes
statements where each statement returns many generated keys (e.g. a big
multi-entry VALUES clause or an INSERT INTO ... SELECT ...), as it
assumes each execution will only return one generated key. That's a
fairly reasonable assumption, given that the lack of intra-statement
ordering guarantees means you can't reliably associate generated keys to
the values that generated them unless you run one statement per
generated result. I don't expect this to be an issue in practice. In any
case, anyone who's doing this is likely to be doing so as an attempt to
work around the very limitation this commit fixes.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Vitalii Tymchyshyn | 2014-10-13 15:33:46 | Re: Disk buffering of resultsets |
Previous Message | Craig Ringer | 2014-10-10 06:19:40 | Re: Network error |