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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
