Re: postgresql and process titles
От | Tom Lane |
---|---|
Тема | Re: postgresql and process titles |
Дата | |
Msg-id | 632.1150305717@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: postgresql and process titles (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: postgresql and process titles
|
Список | pgsql-hackers |
Greg Stark <gsstark@mit.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
В списке pgsql-hackers по дате отправления: