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
> 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 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
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
