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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] explain tup_fetched/returned in monitoring-stats
Date: 2013-01-27 04:18:38
Message-ID: CA+Tgmoa_QB3NVxWJpcRJROKvM5k=eQiqvi1T9oUNycLRFyaD7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Oct 20, 2012 at 2:43 AM, 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.

I guess I'd LIKE to see:

- index tuples fetched by index scans
- heap tuples fetched by index scans (not necessarily the same because
of HOT chains)
- index tuples fetched by index-only scans
- heap tuples fetched by index-only scans
- index tuples fetched by bitmap index scans
- heap tuples fetched by bitmap index scans
- heap tuples fetched by sequential scans

...and then, within that, it might be useful to break it down by
buffers hit vs. buffers missed. However, that's probably more
counters than we can afford with the current stats infrastructure.

However, if I get to dream...

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-01-27 04:23:02 Re: Enabling Checksums
Previous Message Robert Haas 2013-01-27 04:15:10 Re: allowing privileges on untrusted languages