pg_stat_activity provides a way to get a snapshot of what every client on the server is currently doing. Because it includes a process ID, on UNIX-like systems pg_stat_activity is also useful to line up with information collected at the operating system level, by utilities such as top or ps.
The simplest thing to do with this view is to count how many client backends are currently active:
Since the query itself will normally appear in the results, that's filtered out by looking up its process id and excluding it. This is a good practice to get into for queries against this view. This total gives you an idea how close you are to reaching the server's max_connections at any time, and monitoring a high-water mark for its value is a good practice to let you know when you're likely to exceed it.
You can use pg_stat_activity to see how long a backend has been running and whether it's waiting for anything right now:
This shows a couple of common tricks to get output from pg_stat_activity down to a manageable set. In addition to blocking the query itself, the very large query text is cut down to a reasonable size to fit on the screen.
This example also demonstrates two issues that you can run into that aren't so easy to fix. One is that when a backend client has stopped doing work, it will appear as either <IDLE> or <IDLE> in transaction. In either case, you cannot tell what that client was doing just before becoming idle, so once it's reached an idle state you have limited ability to figure out how it got there.
The second issue you're much less likely to run into is the negative runtime shown in one row here. The PostgreSQL system time functions that current_timestamp belongs to return the time of the current transaction for the client asking for the information. If someone else starts a session after yours, but before you run the query against pg_stat_activity, they can have a transaction or query start after what your client believes to be the current time. It's possible to get the true system time instead using the timeofday() function. Given that that returns a string rather than a true timestamp that you can further manipulate, it normally isn't worth the effort to avoid this rare situation. In most cases, you should be more interested in long-running transactions rather than just started ones anyway.