> Perhaps more aggressive autovacuum settings could help, but we've not gotten far enough to tell yet.
Well, I can report that changing the autovacuum settings does indeed help. I added this to all of the `setUpClass`
methodsof our test code:
ALTER TABLE "DataRepo_peakdata" SET (autovacuum_vacuum_scale_factor = 0.0);
ALTER TABLE "DataRepo_peakdata" SET (autovacuum_vacuum_threshold = 5000);
ALTER TABLE "DataRepo_peakdata" SET (autovacuum_analyze_scale_factor = 0.0);
ALTER TABLE "DataRepo_peakdata" SET (autovacuum_analyze_threshold = 5000);
The one query I've been testing with reproducibly runs in a fraction of a second and when I run the entire test suite
ongithub, it runs in 33 minutes as opposed to an hour, which is close to on par with how it was running in postgres 10.
It's also notable that I have not been able to get this speed improvement using a `VACUUM FULL ANALYZE`, though I can't
besure I ever did it correctly in the first place.
The above was based on the feedback you guys provided and the following blog post:
https://www.lob.com/blog/supercharge-your-postgresql-performance
I still don't like the fact that we have this database-architecture-specific code in our code-base that ties it to a
specificdatabase. I'm not sure if where I put it is the best place for it either. Is there a config file I can put
thesesettings in?
And I'm still curious why this wasn't necessary in postgres 10?
Rob