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

Поиск
Список
Период
Сортировка
От Abhijit Menon-Sen
Тема Re: [PATCH] explain tup_fetched/returned in monitoring-stats
Дата
Msg-id 20121020064326.GA12622@toroid.org
обсуждение исходный текст
Ответ на Re: [PATCH] explain tup_fetched/returned in monitoring-stats  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [PATCH] explain tup_fetched/returned in monitoring-stats
Re: [PATCH] explain tup_fetched/returned in monitoring-stats
Список pgsql-hackers
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.

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit kapila
Дата:
Сообщение: Re: [WIP PATCH] for Performance Improvement in Buffer Management
Следующее
От: Jeremy Evans
Дата:
Сообщение: Re: Always include encoding of database in pg_dumpall