On Sat, Oct 20, 2012 at 2:43 AM, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote:
> 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.
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