Re: CLOG extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Daniel Farina <daniel(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLOG extension
Date: 2012-05-03 21:34:16
Message-ID: 15614.1336080856@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2012-05-03 21:36:32 Re: Have we out-grown Flex?
Previous Message Daniel Farina 2012-05-03 21:28:17 Re: CLOG extension