From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] explain tup_fetched/returned in monitoring-stats |
Date: | 2012-10-20 11:27:16 |
Message-ID: | CA+U5nM+i-QgObaBCX0M6qJyRCF0adxmmbJoPR2usiwKoGkGLpA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-10-20 12:47:13 | Re: Bugs in CREATE/DROP INDEX CONCURRENTLY |
Previous Message | Simon Riggs | 2012-10-20 09:26:31 | Re: Foreign key constraint on sub-column of composite-type column |