Re: Per backend relation statistics tracking - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Per backend relation statistics tracking
Date
Msg-id CAA5RZ0vi11ut34nqFkzvrE=PqotnE1OpZMPc0jyCDddNEAY-3g@mail.gmail.com
Whole thread Raw
In response to Per backend relation statistics tracking  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Per backend relation statistics tracking
List pgsql-hackers
Thanks for the patches.

I have not gone through them in detail yet, but +1 on adding backend activity
stats. This provides another level of drill down to spot anomalous sessions or
different patterns across applications. I also think we will want more than
just relation stats. For example, columns from pg_statio already look useful on
a per-backend aggregate level. Beyond that, I can imagine future additions like
number of transactions, subtransactions, I/O stats, conflicts, etc. All of these
seem like valuable per-backend aggregates.

That is why I think we should be careful about naming. pg_stat_backend feels
very generic, but right now it only shows relation stats. Maybe we call it
pg_stat_backend_tables to start? Then if we later add I/O, we could have
pg_stat_backend_io, or for conflicts, pg_stat_backend_conflicts, etc. That way
we keep things more flexible, instead of trying to fit everything into
one view. It also helps us avoid having to rename views in the future.

What do you think?

--
Sami Imseih
Amazon Web Services (AWS)



pgsql-hackers by date:

Previous
From: Vicky Vergara
Date:
Subject: END is not a reserved word
Next
From: Tomas Vondra
Date:
Subject: Re: Changing the state of data checksums in a running cluster