Re: [PATCH] explain tup_fetched/returned in monitoring-stats - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] explain tup_fetched/returned in monitoring-stats
Date
Msg-id 10086.1350061544@sss.pgh.pa.us
Whole thread Raw
In response to [PATCH] explain tup_fetched/returned in monitoring-stats  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: [PATCH] explain tup_fetched/returned in monitoring-stats  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Deprecating RULES
Next
From: Josh Berkus
Date:
Subject: Re: Measure Theoretic Data Types in Postgresql