Efter mycket testande upptäckte jag så småningom att problemet inte var i Entity framework eller NpgSql alls, men fördröjningen jag såg orsakades av skrivcache. Jag skrev alltid en 30MB fil innan jag infogade en rad i tabell 1 och jag trodde att filskrivningen gjordes efter att File.WriteAllBytes återvände så att det inte skulle påverka några framtida timing uttalanden. Men i OS-lagret var det inte riktigt färdigskrivet till disken när insert-satsen kördes, vilket gjorde att insert-satsen försenades på konstgjord väg.
Jag bevisade detta med följande kod:
Stopwatch sw1 = new Stopwatch();
sw1.Start();
File.WriteAllBytes(myBytes);
sw1.Stop();
Thread.Sleep(1000);
Stopwatch sw2 = new Stopwatch();
sw2.Start();
MethodThatInsertsIntoTable1();
sw2.Stop();
stoppur 1 visade att File.WriteAllBytes alltid tog cirka 500 ms, sedan tog stoppur 2 cirka 20 till 30 sekunder.
Om jag ändrar MethodThatInsertsIntoTable1 för att infoga i en annan tabell tar det fortfarande 20 till 30 sekunder oavsett tabell.
Om jag ökar Thread.Sleep(1000) till Thread.Sleep(30000) så registrerar stoppur 2 att infogningen tar mindre än 10 millisekunder.
Detta visar att även efter att File.WriteAllBytes återställer kontrollen till programmet, är det faktiskt inte riktigt färdigt att skriva filen till disken.
Miljön jag körde på var linux på en raspberry pi. Ett skrivhastighetstest bekräftar att min skrivhastighet till sd-kortet är drygt 1MB/s vilket skulle stämma överens med resultaten jag ser, 20-30 sekunder för att skriva en 30MB-fil, det kunde omöjligt göras på 500ms att stoppur 1 säger att det var det.
En annan användare verkar uppleva ett problem på grund av detta i File.WriteAllBytes gör inte blockera
Efter att ha lagt till en extern SSD USB-hårddisk till raspberry pi och ändrat för att spara filen där istället, tar det bara 0,5 sekunder att spara filen och problemet försvinner.