On Thu, May 3, 2012 at 2:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@commandprompt.com> writes: >> Excerpts from Daniel Farina's message of jue may 03 17:04:03 -0400 2012: >>> I sort of care about this, but only on systems that are not very busy >>> and could otherwise get by with fewer resources -- for example, it'd >>> be nice to turn off autovacuum and the stat collector if it really >>> doesn't have to be around. Perhaps a Nap Commander[0] process or >>> procedure (if baked into postmaster, to optimize to one process from >>> two) would do the trick? > >> I'm not sure I see the point in worrying about this at all. I mean, a >> process doing nothing does not waste much resources, does it? Other >> than keeping a PID that you can't use for other stuff. > > Even more to the point, killing a process and then relaunching it > whenever there's something for it to do seems likely to consume *more* > resources than just letting it sit. (So long as it's only just sitting, > of course. Processes with periodic-wakeup logic are another matter.) > > Note that I'm not particularly in favor of having Yet Another process > just to manage clog extension; the incremental complexity seems way > more than anyone has shown to be justified. But the "resources" > argument against it seems pretty weak.
I agree with that; I think that another incremental process addition doesn't really cause concern for me. Rather, I meant to suggest that the only optimization that could really have an effect for me is going from N background processes to, say, 1, or 0 (excluding postmaster) on idle databases. Four to five or five to seven won't really be a big change. And, as per my last thread about lock shmem sizing and how it gets involved with hot standby I have much more serious problems to worry about anyway. I do seem to recall that I measured the number of dirty pages for a idle postgres database at maybe about a megabyte (a few processes times a couple hundred K or so). Ideally, I'd really like to be able to run a functional Postgres cluster in 10MB or less, although getting the most out of even 100MB would be a big step forward for now. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
