From: | Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] explain tup_fetched/returned in monitoring-stats |
Date: | 2012-10-20 06:43:27 |
Message-ID: | 20121020064326.GA12622@toroid.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At 2012-10-15 10:28:17 -0400, robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Abhijit Menon-Sen | 2012-10-20 07:19:03 | Re: patch to add \watch to psql |
Previous Message | Amit kapila | 2012-10-20 06:00:52 | Re: [WIP PATCH] for Performance Improvement in Buffer Management |