> > 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?
>
> My initial idea was to provide just a single view for "basic" counters (i.e
> things that do not need multiple lines per backend (like pg_stat_get_backend_io()
> output would need). That would mean a single view for "basic" counters and
> a set of functions for more "sophisticated" ones (like pg_stat_get_backend_io())
> that need multiple rows per backend. Having said that, we could imagine adding
> pg_stat_get_backend_wal() output to pg_stat_backend too.
>
> Thoughts?
The data that is multiple rows per backend is unique from that perspective.
The stuff we are talking about now will be one row with data aggregated up
to the PID.
I worry that a single view will grow very wide, and we will have to eventually
split it. So we may as well start thinking about having multiple views
in advance.
> Having said that, we could imagine adding
> pg_stat_get_backend_wal() output to pg_stat_backend too.
For this one, I think we should just overload the function
pg_stat_get_backend_wal,
and if a PID is not passed in, return all of them; and just create a
new view called
pg_stat_backend_wal that returns all the PIDs. sort of like how we have
pg_stat_get_activity and pg_stat_activity, etc.
Would that not be more consistent?
--
Sami
