> 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
