On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote: > Concerning keeping PGPROC size as small as possible, I agree that it is > reasonable argument. > But even now it is very large (816 bytes) and adding extra 8 bytes will > increase it on less than 1%.
It does not mean that we should add all kind of things to PGPROC as that's a structure sensitive enough already.
Right. It's not as critical as PGXACT, but PGPROC is still significant for scalability and connection count limits.
It's a shame we can't really keep most of it in backend-private memory and copy it to requestors when they want it, say into a temporary DSA or over a shm_mq. But our single threaded model means we just cannot rely on backends being responsive in a timely enough manner to supply data on-demand. That doesn't mean we have to push it to PGPROC though: we could be sending the parts that don't have to be super-fresh to the stats collector or a new related process for active session stats and letting it aggregate them.
That's way beyond the scope of this patch though. So personally I'm OK with the new PGPROC field. Visibility into Pg's activity is woefully limited and something we need to prioritize more.