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:

Reply via email to