Adam B wrote on 02.05.2009 00:48:
Strange indeed. Perhaps there's some background stuff happening that
messes with the results (auto VACUUM?).
In my mind, however, it makes sense that it would take longer: 2 extra
operations against the server (save&release).
Typical case of "problem sits b
Adam B wrote:
> Hello all,
>
> Is it possible to prevent Postgre from aborting the transaction upon a
> constraint violation?
Not without use of savepoints.
What I like to do is bulk-insert the suspect data into a temp table
without constraints, then INSERT INTO ... SELECT it into the target
ta
Perhaps I'm doing something wrong. I'm consistently taking over 20s for
the following test case. (Without savepoints it takes under 10s)
CREATE TABLE lots2
(
lid serial NOT NULL,
"name" character varying(64),
CONSTRAINT lots2pk PRIMARY KEY (lid),
CONSTRAINT lots2_unique_name UNIQUE (nam
I'm intrigued by this solution, Johan. It might be just the ticket!
I'll do some benchmarks when I have time in a week or so.
Johan Nel wrote:
Adam
B wrote:
Hello all,
Is it possible to prevent Postgre from aborting the transaction upon a
constraint violation?
>From th
Strange indeed. Perhaps there's some background stuff happening that
messes with the results (auto VACUUM?).
In my mind, however, it makes sense that it would take longer: 2 extra
operations against the server (save&release).
Thomas Kellerer wrote:
Adam B
wrote on 01.05.2009 22:59:
Perh
Adam B wrote on 01.05.2009 22:59:
Perhaps I'm doing something wrong. I'm consistently taking over 20s for
the following test case. (Without savepoints it takes under 10s)
That's really strange. I can reproduce your results on my computer (25 vs. 65
seconds).
When running my import progra
Adam B wrote on 01.05.2009 19:50:
I realize that I could set a save-point before every INSERT but that
nearly doubles the processing time.
That's interesting.
I did a quick test with JDBC inserting 500,000 rows and the time when using a
savepoint for each INSERT was not really different to t
Adam B wrote:
Hello all,
Is it possible to prevent Postgre from aborting the transaction upon a
constraint violation?
From the help files maybe the following could get you on the right track:
This example uses exception handling to perform either UPDATE or INSERT,
as appropriate:
CREATE TAB
Hello all,
Is it possible to prevent Postgre from aborting the transaction upon a
constraint violation?
Using JDBC if I catch the constraint violation and try another statement
I get:
/ERROR: current transaction is aborted, commands ignored until end of
transaction block/
I realize that I
