Greg Stark <[EMAIL PROTECTED]> 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
---------------------------(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
