On Tue, Jun 13, 2006 at 05:05:31PM -0400, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly