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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] explain tup_fetched/returned in monitoring-stats
Date: 2013-01-25 21:48:51
Message-ID: 20130125214851.GU6848@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 20, 2012 at 12:27:16PM +0100, Simon Riggs wrote:
> On 20 October 2012 07:43, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
> > 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.
>
> We already have the second one on pg_stat_all_tables.
>
> A third possibility exists, which is the one Tom described above.
>
> Collecting information at pg_stat_database level isn't interesting
> anyway (to me) for information that can be collected at table level.

Added to TODO:

Restructure pg_stat_database columns tup_returned and tup_fetched to
return meaningful values

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-01-25 21:55:48 Re: has_language_privilege returns incorrect answer for non-superuser
Previous Message Tom Lane 2013-01-25 21:37:58 Re: Why will hashed SubPlan not use multiple batches