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 20121020064326.GA12622@toroid.org
Whole thread Raw
In response to Re: [PATCH] explain tup_fetched/returned in monitoring-stats  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] explain tup_fetched/returned in monitoring-stats  (Simon Riggs <simon@2ndQuadrant.com>)
Re: [PATCH] explain tup_fetched/returned in monitoring-stats  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
At 2012-10-15 10:28:17 -0400, robertmhaas@gmail.com wrote:
>
> > Is there any concise description that applies? […]
>
> I don't think there is.  I think we need to replace those counters
> with something better.  The status quo is quite bizarre.

Fair enough. Do you have any ideas?

I see two possibilities: first, they could become the tuple analogue of
blks_read and blks_hit, i.e. tuples fetched from disk, and tuples found
in memory. (I don't know if there's a simple way to count that, and I'm
not sure it would be very useful; we have blks_{read,hit} after all.)

Second, it could do what I thought it did, which is count tuples fetched
by sequential and index scans respectively. I'm not sure how useful the
values would be, but at least it's information you can't get elsewhere.

Also, what are the compatibility implications of changing this? I don't
think anyone is using the current *values*, but I imagine that changing
the column names might break some people's queries.

(I don't feel strongly about any course of action here. I just think the
current situation is unhelpful, and if there's a consensus about what to
change—whether code or documentation—I'm willing to do the work.)

-- Abhijit



pgsql-hackers by date:

Previous
From: Amit kapila
Date:
Subject: Re: [WIP PATCH] for Performance Improvement in Buffer Management
Next
From: Jeremy Evans
Date:
Subject: Re: Always include encoding of database in pg_dumpall