Thanks Laurenz for taking the time to look at this.
> That is unavoidable, because PostgreSQL adds a new version for each row to
> the table. To avoid that kind of bloat, you'd have to update in smaller
> batches and run VACUUM between those to free the "dead" row versions.
Yes, I would expect
> PostgreSQL has a lot of overhead per row.
Okay, thanks. I'm not actually too worried about this since in my scenario,
each row is about 1.5 kB, so the % overhead is negligible.
> It is probably not the lookup, but the *modification* of the index that is
> slow.
Yes that makes sense for the o
Thanks Renan! Reducing the fill factor has improved my update performance and I
am now seeing the same time for updates as inserts.
I look forward to any advancements PostgreSQL may make in the future to improve
the performance of bulk DML operations. It would be amazing if they could be
par
Hello! I'm building a system that needs to insert/update batches of millions
of rows (using INSERT .. ON CONFLICT (.) DO UPDATE) in a single database
transaction, where each row is about 1.5 kB. The system produces about 3
million rows (about 4.5 GB) of data in about 5 seconds, but PostgreSQL takes
