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. > nobody particularly liked the approach it's taking. I think we should > investigate rewriting the stats communication architecture entirely --- > in particular, do we really need the stats buffer process at all? It'd > be interesting to see what happens if we just make the collector process > read the UDP socket directly. Or alternatively drop the UDP socket in Agreed, that's what I would prefer, and tested something like that, but even pulling the packet into the buffer and throwing them away had significant overhead, so I think the timeout trick has to be employed as well as going to a single process. > favor of having the backends write directly to the collector process' > input pipe (not sure if this would port to Windows though). > > 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? -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match