> Um ... true with respect to autovacuum, perhaps, but what about > checkpoints? A standalone backend will never perform a checkpoint > unless explicitly told to.
Hmmm, that's definitely an issue. > (Before we invented the bgwriter, the > postmaster was in charge of launching checkpoints every so often.) > Again, this is probably just what you want for disaster recovery, but > it wouldn't be terribly friendly for an embedded-database application. Yeah, we'd have to put in a clock-based thing which did checkpoints every 5 minutes and VACUUM ANALYZE every hour or something. That seems like a chunk of extra code. > In general I think the selling point for such a feature would be "no > administrative hassles", and I believe that has to go not only for the > end-user experience but also for the application-developer experience. > If you have to manage checkpointing and vacuuming in the application, > you're probably soon going to look for another database. Well, don't discount the development/testing case. If you do agile or TDD (a lot of people do), you often have a workload which looks like: 1) Start framework 2) Start database 3) Load database with test data 4) Run tests 5) Print results 6) Shut down database In a case like that, you can live without checkpointing, even; the database is ephemeral. In other words, let's make this a feature and document it for use in testing, and that it's not really usable for production embedded apps yet. -- 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
