Re: [PATCH] explain tup_fetched/returned in monitoring-stats
От | Simon Riggs |
---|---|
Тема | Re: [PATCH] explain tup_fetched/returned in monitoring-stats |
Дата | |
Msg-id | CA+U5nM+i-QgObaBCX0M6qJyRCF0adxmmbJoPR2usiwKoGkGLpA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] explain tup_fetched/returned in monitoring-stats (Abhijit Menon-Sen <ams@2ndQuadrant.com>) |
Ответы |
Re: [PATCH] explain tup_fetched/returned in
monitoring-stats
|
Список | pgsql-hackers |
On 20 October 2012 07:43, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote: > At 2012-10-15 10:28:17 -0400, robertmhaas@gmail.com wrote: >> >> > Is there any concise description that applies? […] >> >> I don't think there is. I think we need to replace those counters >> with something better. The status quo is quite bizarre. > > Fair enough. Do you have any ideas? > > I see two possibilities: first, they could become the tuple analogue of > blks_read and blks_hit, i.e. tuples fetched from disk, and tuples found > in memory. (I don't know if there's a simple way to count that, and I'm > not sure it would be very useful; we have blks_{read,hit} after all.) > > Second, it could do what I thought it did, which is count tuples fetched > by sequential and index scans respectively. I'm not sure how useful the > values would be, but at least it's information you can't get elsewhere. We already have the second one on pg_stat_all_tables. A third possibility exists, which is the one Tom described above. Collecting information at pg_stat_database level isn't interesting anyway (to me) for information that can be collected at table level. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: