Re: CLOG extension - Mailing list pgsql-hackers

From Daniel Farina
Subject Re: CLOG extension
Date
Msg-id CAAZKuFawsbqA9B0-znS-DeW8dBVQM2VgVCS2AYFHuevx5r9j8A@mail.gmail.com
Whole thread Raw
In response to Re: CLOG extension  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, May 3, 2012 at 2:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@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


pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Have we out-grown Flex?
Next
From: Peter Geoghegan
Date:
Subject: Re: Latch for the WAL writer - further reducing idle wake-ups.