Timeline for Postgres Upsert Performance Considerations (millions of rows/hour)
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 9, 2023 at 2:00 | comment | added | mike01010 | what happens if you do a COPY from stdin if the table has primary key that would cause conflicts? are they ignorned or u get an exception? | |
| Sep 5, 2019 at 14:26 | comment | added | fgblomqvist | Right okay yeah makes sense. Thanks again! :) | |
| Sep 5, 2019 at 14:15 | comment | added | Laurenz Albe |
Right. fillfactor wastes some space, but you'll gladly pay that price if it allows you to to survive lots of updates. Remember that this is not necessary if you use ON CONFLICT DO NOTHING.
|
|
| Sep 5, 2019 at 14:12 | comment | added | fgblomqvist |
Oh okay, that's good. Are there any cons of setting a lower fillfactor? It sounds like it might cause more pages having to be loaded into memory since less data fits on each page. I suppose that's not necessarily a bad thing though if we can avoid having to aggressively auto vacuum.
|
|
| Sep 5, 2019 at 12:50 | comment | added | Laurenz Albe | That is not a failed insertm and no dead tuple will be generated. It is called a speculative insert. | |
| Sep 5, 2019 at 11:53 | comment | added | fgblomqvist | I see. Aren't dead tuples created from failed inserts? I thought it first wrote the data to somewhere, then checked conflicts, and if conflicted, mark the data as dead. The rest of what you said makes sense, I will have to read up on the fillfactor stuff, thanks for your help! | |
| Sep 5, 2019 at 6:41 | history | answered | Laurenz Albe | CC BY-SA 4.0 |