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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] explain tup_fetched/returned in monitoring-stats
Date: 2012-10-12 17:05:44
Message-ID: 10086.1350061544@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2012-10-12 17:06:41 Re: Measure Theoretic Data Types in Postgresql
Previous Message Pavel Stehule 2012-10-12 17:00:31 patch: assign result of query to psql variable