Re: CLOG extension

On Thu, May 3, 2012 at 2:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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