Re: [PATCH] explain tup_fetched/returned in monitoring-stats

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] explain tup_fetched/returned in monitoring-stats
Дата
Msg-id 10086.1350061544@sss.pgh.pa.us
обсуждение исходный текст
Ответ на [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
Abhijit Menon-Sen <ams@2ndQuadrant.com> writes:
> I'm making some changes to a program that, among other things, reports
> tup_fetched/tup_returned as if it were a cache hit rate, analogous to
> blks_hit/blks_fetched.

> The documentation didn't help me to understand if that was appropriate,
> so I looked at the source and asked on IRC. It seems I'm not the first
> person to be confused by these descriptions, so here's a tiny patch to
> clarify the meaning of fetched and returned.

It may be tiny, but I don't believe it's correct.  t_tuples_returned for
instance is incremented by both pgstat_count_heap_getnext() (ie,
successful returns from heap_getnext()) and pgstat_count_index_tuples()
(which counts heap TIDs returned from either index_getnext_tid or
index_getbitmap).  t_tuples_fetched is incremented by
pgstat_count_heap_fetch(), which is called in heap_fetch and
index_fetch_heap.

Right at the moment it's not obvious to me that these calls are usefully
placed.  My intuitive understanding of "fetched" vs "returned" is that
the former should count physical tuple visits while the latter should
count tuples that satisfied some qual or other.  It doesn't seem like
the implementation actually squares with that.  But in any case,
indexscan vs heapscan is a completely wrong description of the
difference.
        regards, tom lane



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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Deprecating RULES
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Measure Theoretic Data Types in Postgresql