Re: postgresql and process titles

On Tue, Jun 13, 2006 at 05:05:31PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > Jim C. Nasby wrote:
> > >> Excellent. Did I miss discussion of that or have you not mentioned it?
> > >> I'm curious as to how you're fixing it...
> >
> > > The patches are in the hold queue:
> > > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> >
> > That's talking about the stats code, which has approximately zip to do
> > with setproctitle (ps_status.c). But IIRC that patch is on hold because
>
> I thought the bug reporter was asking about the stats code was well.

It did get brought up...

> > As far as Kris' complaint goes, one thing that might be interesting is
> > to delay both the setproctitle call and the stats command message send
> > until the current command has been running a little while (say 100ms
> > or so). The main objection I see to this is that it replaces a kernel
> > call that actually does some work with a kernel call to start a timer,
> > plus possibly a later kernel call to actually do the work. Not clear
> > that there's a win there. (If you're using statement_timeout it might
> > not matter, but if you aren't...)
> >
> > Also not clear how you make the necessary actions happen when the timer
> > expires --- I seriously doubt it'd be safe to try to do either action
> > directly in a signal handler.
>
> Right. What if the postmaster signals the backend once a second to do
> their reporting. I am not sure what the final solution will be, but we
> _need_ one based on the performance numbers I and others have seen.
> Could we have PGPROC have a reporting boolean that is set every second
> and somehow checked by each backend?

One second might be a bit more delay than some folks want... it would be
nice if this was tuneable. Also, what would the overhead on this look
like if there's a large number of idle backends?

It does sound more appealing than setting a timer every time you start a
transaction, though...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461