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

From Abhijit Menon-Sen
Subject Re: [PATCH] explain tup_fetched/returned in monitoring-stats
Date
Msg-id 20121012180540.GA11528@toroid.org
Whole thread Raw
In response to Re: [PATCH] explain tup_fetched/returned in monitoring-stats  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] explain tup_fetched/returned in monitoring-stats  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
At 2012-10-12 13:05:44 -0400, tgl@sss.pgh.pa.us wrote:
>
> 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).

But pgstat_count_index_tuples() is called only on the index relation,
right? And pgstat_count_heap_fetch() is called by index_fetch_heap on
the index relation too.

Earlier, I thought that pgstat_recv_tabstat() adds t_tuples_fetched and
t_tuples_returned only for tables to the database stats (as the comments
and variable names suggest), but it makes more sense for it to include
index relations too (and the code in pgstat_initstats does imply that's
what is happening).

> But in any case, indexscan vs heapscan is a completely wrong
> description of the difference.

Yes. I'm sorry. Is there any concise description that applies? I think
it's worth fixing, seeing that multiple competent people have got the
wrong idea about what it means.

-- Abhijit



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: dumping recursive views broken in master
Next
From: Stephen Frost
Date:
Subject: Re: Support for REINDEX CONCURRENTLY