On Thu, Dec 12, 2019 at 09:31:22AM +0800, Craig Ringer wrote: > On Fri, 6 Dec 2019 at 09:57, Michael Paquier <mich...@paquier.xyz> wrote: > > 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.
Uh, how much does the new field get us near the CPU cache line max size for a single PGPROC entry? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
