Re: monitoring usage count distribution

Поиск
Список
Период
Сортировка
От Melanie Plageman
Тема Re: monitoring usage count distribution
Дата
Msg-id CAAKRu_bvV2_apXjDZ0bw8Ljqx0eN5=hPAn35fYPZq6j6K0ftFQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: monitoring usage count distribution  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Apr 4, 2023 at 2:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Jan 30, 2023 at 6:30 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
> >> My colleague Jeremy Schneider (CC'd) was recently looking into usage count
> >> distributions for various workloads, and he mentioned that it would be nice
> >> to have an easy way to do $SUBJECT.
>
> > I'm skeptical that pg_buffercache_summary() is a good idea at all, but
> > having it display the average usage count seems like a particularly
> > poor idea. That information is almost meaningless. Replacing that with
> > a six-element integer array would be a clear improvement and, IMHO,
> > better than adding yet another function to the extension.
>
> I had not realized that pg_buffercache_summary() is new in v16,
> but since it is, we still have time to rethink its definition.
> +1 for de-aggregating --- I agree that the overall average is
> unlikely to have much value.

So, I have used pg_buffercache_summary() to give me a high-level idea of
the usage count when I am benchmarking a particular workload -- and I
would have found it harder to look at 6 rows instead of 1. That being
said, having six rows is more versatile as you could aggregate it
yourself easily.

- Melanie



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Следующее
От: Kirk Wolak
Дата:
Сообщение: Re: psql \watch 2nd argument: iteration count