Me gustaría proponer otro pensamiento para abordar específicamente su oración: "Así que quiero verificar si existe una sola fila del lote en la tabla porque sé que todas fueron insertadas ".
¿Estás haciendo las cosas eficientes insertando en "lotes" pero luego haciendo verificaciones de existencia un registro a la vez? Esto me parece contrario a la intuición. Entonces, cuando dices "las inserciones siempre se hacen en lotes ", entiendo que estás insertando múltiples registros con una declaración de inserción . Debe darse cuenta de que Postgres es compatible con ACID. Si está insertando múltiples registros (un lote de datos) con una declaración de inserción , no es necesario verificar si algunos se insertaron o no. La declaración pasa o fallará. Todos los registros serán insertados o ninguno.
Por otro lado, si su código C # simplemente está haciendo un "conjunto" de instrucciones de inserción separadas, por ejemplo, en un bucle, y en su mente, esto es un "lote" ... entonces, de hecho, no debe describirlo como " las inserciones siempre se realizan en lotes ". El hecho de que espere que parte de lo que llama un "lote" en realidad no se pueda insertar y, por lo tanto, sienta la necesidad de una verificación, sugiere que este es el caso, en cuyo caso tiene un problema más fundamental. Necesita cambiar su paradigma para insertar realmente varios registros con una inserción y renunciar a verificar si los registros individuales lo hicieron.
Considere este ejemplo:
CREATE TABLE temp_test (
id SERIAL PRIMARY KEY,
sometext TEXT,
userid INT,
somethingtomakeitfail INT unique
)
-- insert a batch of 3 rows
;;
INSERT INTO temp_test (sometext, userid, somethingtomakeitfail) VALUES
('foo', 1, 1),
('bar', 2, 2),
('baz', 3, 3)
;;
-- inspect the data of what we inserted
SELECT * FROM temp_test
;;
-- this entire statement will fail .. no need to check which one made it
INSERT INTO temp_test (sometext, userid, somethingtomakeitfail) VALUES
('foo', 2, 4),
('bar', 2, 5),
('baz', 3, 3) -- <<--(deliberately simulate a failure)
;;
-- check it ... everything is the same from the last successful insert ..
-- no need to check which records from the 2nd insert may have made it in
SELECT * FROM temp_test
De hecho, este es el paradigma para cualquier DB compatible con ACID ... no solo Postgresql. En otras palabras, estará mejor si arregla su concepto de "lote" y evita tener que hacer verificaciones fila por fila en primer lugar.