Re: top for postgresql (ptop?)

Hi Greg,

On 9/25/07 9:15 PM, "Greg Smith" <gsmith(at)gregsmith(dot)com> wrote:

> It's also worth noting that there's a similar Linux utility called gstack.

Cool!

So - the basic idea is that we could uncover the current run context in a
very lightweight manner by just dumping the stack and interpreting it. This
is pretty messy on the client side because of the ugly reconstruction, but
is very unobtrusive to the running query.

An alternative might be to take the plan tree, augment it with stats and
store it in a table, maybe augment the backend to catch a certain signal
(SIGUSR maybe?) and that would cause an update to the table? That way we'd
have the desired feature that the tracking isn't continuous, it's based on a
"peek" approach, which is only as obtrusive as needed.

- Luke