At Thu, 1 Oct 2020 09:05:19 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in
>
>
> On 2020/09/30 20:21, Amit Kapila wrote:
> > On Tue, Sep 29, 2020 at 9:23 PM Fujii Masao
> > <masao.fujii@oss.nttdata.com> wrote:
> >>
> >> On 2020/09/29 11:51, Masahiro Ikeda wrote:
> >>> On 2020-09-29 11:43, Amit Kapila wrote:
> >>>> On Tue, Sep 29, 2020 at 7:39 AM Masahiro Ikeda
> >>>> <ikedamsh@oss.nttdata.com> wrote:
> >>> Thanks for your suggestion.
> >>> I understood that the point is that WAL-related stats have just one
> >>> counter now.
> >>>
> >>> Since we may add some WAL-related stats like pgWalUsage.(bytes,
> >>> records, fpi),
> >>> I think that the current approach is good.
> >>
> >> +1
> >>
> > Okay, it makes sense to keep it in the current form if we have a plan
> > to extend this view with additional stats. However, why don't we
> > expose it with a function similar to pg_stat_get_archiver() instead of
> > providing individual functions like pg_stat_get_wal_buffers_full() and
> > pg_stat_get_wal_stat_reset_time?
>
> We can adopt either of those approaches for pg_stat_wal. I think that
> the former is a bit more flexible because we can collect only one of
> WAL information even when pg_stat_wal will contain many information
> in the future, by using the function. But you thought there are some
> reasons that the latter is better for pg_stat_wal?
FWIW I prefer to expose it by one SRF function rather than by
subdivided functions. One of the reasons is the less oid consumption
and/or reduction of definitions for intrinsic functions.
Another reason is at least for me subdivided functions are not useful
so much for on-the-fly examination on psql console. I'm often annoyed
by realizing I can't recall the exact name of a function, say,
pg_last_wal_receive_lsn or such but function names cannot be
auto-completed on psql console. "select proname from pg_proc where
proname like.. " is one of my friends:p On the other hand "select *
from pg_stat_wal" requires no detailed memory.
However subdivided functions might be useful if I wanted use just one
number of wal-stats in a function, I think it is not a major usage and
we can use a SQL query on the view instead.
Another reason that I mildly want to object to subdivided functions is
I was annoyed that a stats view makes many individual calls to
functions that internally share the same statistics entry. That
behavior required me to provide an entry-caching feature to my
shared-memory statistics patch.
regrds.
--
Kyotaro Horiguchi
NTT Open Source Software Center