Chciałbym zaproponować inną myśl, aby konkretnie odnieść się do twojego zdania: „Chcę więc sprawdzić, czy w tabeli istnieje pojedynczy wiersz z partii, ponieważ wtedy wiem, że wszystkie zostały wstawione ”.
Robisz rzeczy wydajnie, wstawiając „partie”, ale potem sprawdzanie istnienia sprawdza tylko jeden rekord na raz? Wydaje mi się to sprzeczne z intuicją. Więc kiedy mówisz „ wstawianie zawsze wykonuje się partiami ”, rozumiem, że masz na myśli wstawianie wielu rekordów za pomocą jednej instrukcji wstawiania . Musisz zdać sobie sprawę, że Postgres jest zgodny z ACID. Jeśli wstawiasz wiele rekordów (zestaw danych) za pomocą jednej instrukcji wstawiania , nie ma potrzeby sprawdzania, czy niektóre zostały wstawione, czy nie. Instrukcja przechodzi lub zakończy się niepowodzeniem. Wszystkie rekordy zostaną wstawione lub żadne.
Z drugiej strony, jeśli Twój kod C # po prostu wykonuje „set” oddzielne instrukcje wstawiania, na przykład w pętli, i myślisz, że jest to „partia”… to nie powinieneś opisywać tego jako „ wkładki są zawsze wykonywane partiami ”. Fakt, że spodziewasz się, że część tego, co nazywasz „pakietem”, może w rzeczywistości nie zostać włożona, a zatem odczuwasz potrzebę sprawdzenia, zdecydowanie sugeruje, że tak jest, w takim przypadku masz bardziej podstawowy problem. Musisz zmienić swój paradygmat, aby faktycznie wstawić wiele rekordów za pomocą jednej wstawki i zrezygnować z sprawdzania, czy pojedyncze rekordy to zrobiły.
Rozważmy ten przykład:
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
W rzeczywistości jest to paradygmat dla każdej bazy danych zgodnej z ACID .. nie tylko Postgresql. Innymi słowy, lepiej będzie, jeśli naprawisz koncepcję „partii” i unikniesz konieczności sprawdzania każdego wiersza w pierwszej kolejności.