From: | Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] explain tup_fetched/returned in monitoring-stats |
Date: | 2012-10-12 18:05:40 |
Message-ID: | 20121012180540.GA11528@toroid.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 2012-10-12 13:05:44 -0400, tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2012-10-12 18:17:41 | Re: Support for REINDEX CONCURRENTLY |
Previous Message | Peter Eisentraut | 2012-10-12 18:00:40 | dumping recursive views broken in master |