On Wed, Sep 5, 2012 at 01:50:06PM -0700, Josh Berkus wrote: > 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?
If this mode slows down pg_upgrade, that is going to be a problem. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers