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 по дате отправления: