Re: Report reorder buffer size

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Report reorder buffer size
Дата
Msg-id CAExHW5tfN+RHZBXaAzfUVOfdZuqHr1Jmud8yEzu8Bkv7s2DqMA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Report reorder buffer size  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список pgsql-hackers
>
> >
> > > If we are going
> > > to report so much statistics about the contents of the reorder buffer,
> > > is it better to have a separate view pg_stat_reorder_buffer for the
> > > same?
> >
> > Given logical decoding can be used also by regular backend processes,
> > I guess that such dynamic metrics would fit a system view dedicated to
> > logical decoding, say pg_stat_reorder_buffer or
> > pg_stat_logical_decoding.
>
> Hmm. That means we will have to reserve some area in the shared memory
> with as many slots as the number of replication slots (since that is
> the maximum number of reorder buffers that can be in the system) and
> use each one to maintain the stats. I haven't yet checked whether we
> could use the stats maintaining system for it, but it should be
> doable.

I think the beauty of reporting the statistics only for WAL senders,
as is done with the patch, was that we could piggyback stats update on
current logic to update WalSnd. If we want to do it for other
backends, it would be an extra overhead to lock and update the stats
outside WalSnd. And as I said in my email, WAL senders would be
arguably only serious users of logical decoding whose usage will be
worth monitoring - that's why pg_stat_replication reports only stats
about WAL senders and not other backends. Even if we report stats
about only WAL senders, it should be possible to report them through a
view other than pg_stat_replication. What's your opinion about this?

-- 
Best Wishes,
Ashutosh Bapat



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