Re: shared-memory based stats collector - v70
| От | David G. Johnston |
|---|---|
| Тема | Re: shared-memory based stats collector - v70 |
| Дата | |
| Msg-id | CAKFQuwbqRmfzvJbSVO9ORVzCA1tXmfWQvPdaqXpjHTrA8buJqw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: shared-memory based stats collector - v66 (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: shared-memory based stats collector - v70
|
| Список | pgsql-hackers |
On Wednesday, April 6, 2022, Andres Freund <andres@anarazel.de> wrote:
I'd go for
pgstat_reset_slru_counter() -> pgstat_reset_slru()
pgstat_reset_subscription_counter() -> pgstat_reset_subscription()
pgstat_reset_subscription_counters() -> pgstat_reset_all_ subscriptions()
pgstat_reset_replslot_counter() -> pgstat_reset_replslot()
pgstat_reset_replslot_counters() -> pgstat_reset_all_replslots()
I like having the SQL function paired with a matching implementation in this scheme.
We could leave out the _all_ and just use plural too, but I think it's a bit
nicer with _all_ in there.
+1 to _all_
Not quite sure what to do with pgstat_reset_single_counter(). I'd either go
for the minimal pgstat_reset_single_counters() or pgstat_reset_one()?
Why not add both pgstat_resert_function() and pgstat_reset_table() (to keep the pairing) and they can call the renamed pgstat_reset_function_or_table() internally (since the function indeed handle both paths and we’ve yet to come up with a label to use instead of “function and table stats”)?
These are private functions right?
David J.
В списке pgsql-hackers по дате отправления: