From: | Alvaro Herrera <alvherre(at)surnet(dot)cl> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Federico Di Gregorio <fog(at)initd(dot)org>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [BUGS] BUG #1707: statistics collector starts with stats_start_collector |
Date: | 2005-06-28 01:29:40 |
Message-ID: | 20050628012940.GD15765@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-patches |
On Mon, Jun 27, 2005 at 09:13:20PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > > In fact, if it wasn't started from the beginning, we couldn't enable
> > > query strings without restarting the server.
> >
> > That's true -- if you start with the collector disabled, you can't
> > enable query strings.
>
> OK, but if all the stats* variables are off, what overhead is there in
> having the stats process run? I would think very little, and if we turn
> it always on, we make configuration easier and remove a GUC variable.
What about arranging postmaster's main loop so that it starts the stats
collector process if one of the options is activated (assuming they were
all off at start)? Right now you have to restart the server, but I
don't see why it has to be like that.
That has even less overhead. We will have to keep the GUC var, but I
don't think that's too onerous, is it?
--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"Granting software the freedom to evolve guarantees only different results,
not better ones." (Zygo Blaxell)
From | Date | Subject | |
---|---|---|---|
Next Message | satish reddy | 2005-06-28 01:35:38 | Reg No Error Information Available |
Previous Message | Bruce Momjian | 2005-06-28 01:13:20 | Re: [BUGS] BUG #1707: statistics collector starts with stats_start_collector |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2005-06-28 01:34:19 | Re: Performance analysis of plpgsql code |
Previous Message | Michael Glaesemann | 2005-06-28 01:15:50 | Re: Performance analysis of plpgsql code |