| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Kris Kennaway <kris(at)obsecurity(dot)org>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: postgresql and process titles |
| Date: | 2006-06-14 17:21:57 |
| Message-ID: | 632.1150305717@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> If backends store their current status in shared memory then a separate
> process entirely can receive the interrupts, scan through the shared memory
> process states and do the accounting.
This sounds good until you think about locking. It'd be quite
impractical to implement anything as fine-grained as EXPLAIN ANALYZE
this way, because of the overhead involved in taking and releasing
spinlocks.
It could be practical as a replacement for stats_command_string
messages, though.
I'm not sure about replacing ps_status with this. I don't think there
is a way for one process to set another's status (on most platforms
anyway). You might argue that we could abandon ps_status reporting
altogether if we had something better, but I'm unconvinced ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2006-06-14 17:43:32 | Re: Multi-byte and client side character encoding tests for |
| Previous Message | Bruce Momjian | 2006-06-14 16:57:33 | Re: Question about Ctrl-C and less |