Date: Fri, 26 Nov 2021 15:16:36 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	Magnus Hagander <magnus@hagander.net>, pgsql-hackers@postgresql.org,
	Lukas Fittl <lukas@fittl.com>,
	Thomas Munro <thomas.munro@gmail.com>
Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and
 more?)
Message-ID: <20211126211636.GE17618@telsasoft.com>
References: 
 <CAAKRu_bt1ZQmf-BgZkewPqJXb-voGMe4vqLowB1OtRXtYVVUag@mail.gmail.com>
 <202109302315.65qtfrmgbpzt@alvherre.pgsql>
 <CAAKRu_boF3Yh_PeHs10S-88J3fy3AGCQxHCur6+7tgy78YxJ_g@mail.gmail.com>
 <20211008175620.nspjy6wwmzvyzkrg@alap3.anarazel.de>
 <CAAKRu_YJMHJ66-ZB86zFCH=Cq4+5w2gnJ14bu8oyZec0C39Dcg@mail.gmail.com>
 <20211019192931.eeeohw6yrvqe6bol@alap3.anarazel.de>
 <CAAKRu_Yeg+vh6SHNEo1+=O7e-BPX35cU0XQM=YwQRnkFyv_y+w@mail.gmail.com>
 <20211119164952.mlw7ecj4xxliuuut@alap3.anarazel.de>
 <CAAKRu_bCavNULX2BUM1Ankr=Hc5ySbmMJCGnHCFZBbM=yMvFLA@mail.gmail.com>
 <20211125011559.GC17618@telsasoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211125011559.GC17618@telsasoft.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20211126211636.GE17618%40telsasoft.com>
Precedence: bulk

On Wed, Nov 24, 2021 at 07:15:59PM -0600, Justin Pryzby wrote:
> There's extraneous blank lines in these functions:
> 
> +pgstat_sum_io_path_ops
> +pgstat_report_live_backend_io_path_ops
> +pgstat_recv_resetsharedcounter
> +GetIOPathDesc
> +StrategyRejectBuffer

+ an extra blank line pgstat_reset_shared_counters.

In 0005:

monitoring.sgml says that the columns in pg_stat_buffers are integers, but
they're actually bigint.

+       tupstore = tuplestore_begin_heap(true, false, work_mem);

You're passing a constant randomAccess=true to tuplestore_begin_heap ;)

+Datum all_values[NROWS][COLUMN_LENGTH];

If you were to allocate this as an array, I think it could actually be 3-D:
Datum all_values[BACKEND_NUM_TYPES-1][IOPATH_NUM_TYPES][COLUMN_LENGTH];

But I don't know if this is portable across postgres' supported platforms; I
haven't seen any place which allocates a multidimensional array on the stack,
nor passes one to a function:

+static inline Datum *
+get_pg_stat_buffers_row(Datum all_values[NROWS][COLUMN_LENGTH], BackendType backend_type, IOPath io_path)

Maybe the allocation half is okay (I think it's ~3kB), but it seems easier to
palloc the required amount than to research compiler behavior.

That function is only used as a one-line helper, and doesn't use
multidimensional array access anyway:

+       return all_values[(backend_type - 1) * IOPATH_NUM_TYPES + io_path];

I think it'd be better as a macro, like (I think)
#define ROW(backend_type, io_path) all_values[NROWS*(backend_type-1)+io_path]

Maybe it should take the column type as a 3 arg.

The enum with COLUMN_LENGTH should be named.

Or maybe it should be removed, and the enum names moved to comments, like:

+                       /* backend_type */
+                       values[val++] = backend_type_desc;

+                       /* io_path */
+                       values[val++] = CStringGetTextDatum(GetIOPathDesc(io_path)); 

+                       /* allocs */
+                       values[val++] += io_ops->allocs - resets->allocs;
...

*Note the use of += and not =.

Also:
src/include/miscadmin.h:#define BACKEND_NUM_TYPES (B_LOGGER + 1)

I think it's wrong to say NUM_TYPES = B_LOGGER + 1 (which would suggest using
lessthan-or-equal instead of lessthan as you are).

Since the valid backend types start at 1 , the "count" of backend types is
currently B_LOGGER (13) - not 14.  I think you should remove the "+1" here.
Then NROWS (if it continued to exist at all) wouldn't need to subtract one.

-- 
Justin