Re: [BUGS] BUG #1707: statistics collector starts with stats_start_collector

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)

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-patches by date

  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