FYI, I upgraded my pod to the just-released PostgreSQL 13 and stream load times were cut roughly in half. It’s not a drop-in replacement; you need to do a pg_dump and restore to upgrade your databases, but it seems well worth it.
That’s good to know, thanks.
WTF does the topic name need to be 15 chars?
To have people write meaningful topics. “PostgreSQL 13” is not, whereas “PostgreSQL 13 significantly improves stream performance” would have been more helpful. 
1 Like
Can you please keep us up-to-date with the performance in the coming weeks?
I had that feeling when upgrading to PG11, but then after some weeks the situation looked like before the upgrade. So I wondered if the better performance at the beginning wasn’t due to some reset / cleaning involved by switching the engine…
Sure @flaburgan. I’m basing my results on the timings from Firefox, which shows stream load times went from 3.6s on PG12 to about 1.5s with PG13. Twenty-four hours in I’m still seeing the same results; will advise if things change.
This should not happen. Make sure your autovacuum is enabled and can actually run (check the logs). If you can’t run autovacuum for some reason, make sure to VACUUM FULL ANALYZE; once (but keep in mind that this does require an exclusive table lock for everything) and set up a cron or so that runs VACUUM ANALYZE; regularly. Also, make sure that your database isn’t running into swap space, because postgres does not like that.
I’ll have a look.
@koehn you said the migration had to be done with pg_dump and re-import, why that? pg_upgrade didn’t work?
Two weeks on, and PG13 continues to perform. I’ve since migrated my pod from a single, large bare-metal server to a Kubernetes cluster of smaller nodes sharing a single Postgres database and performance really didn’t change. Your mileage may vary.
And while I’m at it, WAL-G is a phenomenal solution for streaming encrypted Postgres backups to S3-compatible storage. Consider using it instead of pg_dump. I have a Docker image with source code, because of course I do.