On Thu, Dec 12, 2019 at 09:31:22AM +0800, Craig Ringer wrote:
> On Fri, 6 Dec 2019 at 09:57, Michael Paquier <michael@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 <bruce@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 +