Folks, There's currently some great ideas bouncing around about eliminating the overhead associated with FREEZE. However, I wanted to take a step back and take a look at the big picture for VACUUM, FREEZE and ANALYZE. Otherwise, we're liable to repeat the 8.4 problem of making one operation better (background vacuum) while making another one worse (freezing).
The big, big picture is this: 90% of our users need to think about VACUUM/ANALYZE at least 10% of the time and 10% of our users need to think about it almost 90% of the time. That's considerably better than was the case 5 years ago, when vacuum management was a daily or weekly responsibility for nearly 100% of our users, but it's still not good enough. Our target should be that only those with really unusual setups should have to *ever* think about vacuum and analyze. So I've set up a wiki page to document the various problems that force users to think about vacuum and analyze and try to troubleshoot it: https://wiki.postgresql.org/wiki/VacuumHeadaches We can also collect suggested solutions here. I'm looking to create a long-term development target which removes most of these vacuum headaches over the next 3 or 4 releases, without making the unremoved headaches siginficantly worse. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
