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 |