Tom,
> However, there are some additional things
> we'd need to think about before advertising it as a fit solution for that.
> Notably, while the lack of any background processes is just what you want
> for pg_upgrade and disaster recovery, an ordinary application is probably
> going to want to rely on autovacuum; and we need bgwriter and other
> background processes for best performance. So I'm speculating about
> having a postmaster process that isn't listening on any ports, but is
> managing background processes in addition to a single child backend.
> That's for another day though.
Well, if you think about standalone mode as "developer" mode, it's not
quite so clear that we'd need those things. Generally when people are
testing code in development they don't care about vacuum or bgwriter
because the database is small and ephemeral. So even without background
processes, standalone mode would be useful for many users for
development and automated testing.
For that matter, applications which embed postgresql and have very small
databases could also live without autovacuum and bgwriter. Heck,
Postgres existed without them for many years.
You just doc that, if you're running postgres standalone, you need to
run a full VACUUM ANALYZE on the database cluster once per day. And you
live with the herky-jerky write performance. If the database is 5GB,
who's going to notice anyway?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
