Message-ID: <c62e518d-29e5-0271-1b22-1870bc90ff55@enterprisedb.com>
Date: Thu, 24 Feb 2022 10:48:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.0
Subject: Re: Design of pg_stat_subscription_workers vs pgstats
Content-Language: en-US
To: Andres Freund <andres@anarazel.de>,
 Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
 "David G. Johnston" <david.g.johnston@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <CAD21AoA-MVZcMA1iYwbtvTCOHx1SwG8amQUTT8j2ssh2zuc6OQ@mail.gmail.com>
 <20220218203255.d3evl6qi2n6gxy6b@alap3.anarazel.de>
 <CAD21AoDTO3bJvrc39Tv3VCeyUzZpimXnJuRhHQhKyjOWorHeOA@mail.gmail.com>
 <20220219160203.y5w2ktc2utthn7pe@alap3.anarazel.de>
 <CAD21AoA_r+Wc-zJZdy4Lii3oOvvdGcLwrY=2Y4y63HueYSd6Eg@mail.gmail.com>
 <20220221053453.lo6fzmji23ennvgj@alap3.anarazel.de>
 <CAA4eK1+j00Pc+p=AfJLXh-a+OJ-a0UD4adMr2tRkQvKG_LggHA@mail.gmail.com>
 <20220221074806.nyhdberpuwbcbudp@alap3.anarazel.de>
 <CAA4eK1J3dhfMRNQ6Q585nFr1vmXaTXVW9qv4hmUxLwDwJp-9RQ@mail.gmail.com>
 <CAD21AoAtrgBEUU08VvfzRnGS+=9rS=MEq1cTLaZ1OT51xX34dQ@mail.gmail.com>
 <20220223021415.ynybxeroefw4kiwh@alap3.anarazel.de>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
In-Reply-To: <20220223021415.ynybxeroefw4kiwh@alap3.anarazel.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/c62e518d-29e5-0271-1b22-1870bc90ff55%40enterprisedb.com>
Precedence: bulk

On 23.02.22 03:14, Andres Freund wrote:
> Why are the stats stored in the per-database stats file / as a second level
> below the database? While they're also associated with a database, it's a
> global catalog, so it seems to make more sense to have them "live" globally as
> well?

pg_subscription being a global catalog is a bit of a lie for the benefit 
of the worker launcher, but it can be treated as a per-database catalog 
for practical purposes.

> Not just from an aesthetical perspective, but there might also be cases where
> it's useful to send stats from the stats launcher. E.g. the number of times
> the launcher couldn't start a worker because the max numbers of workers was
> already active or such.

That's a reasonable point, however.