> 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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to