Re: monitoring usage count distribution
От | Robert Haas |
---|---|
Тема | Re: monitoring usage count distribution |
Дата | |
Msg-id | CA+TgmobRvYRxubzHY7PgnuYhJHPBGSF8a-6Ax+cz0Fm0EbxGgA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: monitoring usage count distribution (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: monitoring usage count distribution
|
Список | pgsql-hackers |
On Wed, Apr 5, 2023 at 4:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Nathan Bossart <nathandbossart@gmail.com> writes: > > On Wed, Apr 05, 2023 at 12:09:21PM -0700, Andres Freund wrote: > >> I would not mind having a separate function returning 6 rows, if we really > >> want that, but making pg_buffercache_summary() return 6 rows would imo make it > >> less useful for getting a quick overview. At least I am not that quick summing > >> up multple rows, just to get a quick overview over the number of dirty rows. > > > This is what v1-0001 does. We could probably make pg_buffercache_summary a > > view on pg_buffercache_usage_counts, too, but that doesn't strike me as > > tremendously important. > > Having two functions doesn't seem unreasonable to me either. > Robert spoke against it to start with, does he still want to > advocate for that? My position is that if we replace the average usage count with something that gives a count for each usage count, that's a win. I don't have a strong opinion on an array vs. a result set vs. some other way of doing that. If we leave the average usage count in there and add yet another function to give the detail, I tend to think that's not a great plan, but I'll desist if everyone else thinks otherwise. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: