Re: New SQL counter statistics view (pg_stat_sql)

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: New SQL counter statistics view (pg_stat_sql)
Дата
Msg-id 20160921170524.GA897790@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: New SQL counter statistics view (pg_stat_sql)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: New SQL counter statistics view (pg_stat_sql)  (David Fetter <david@fetter.org>)
Re: New SQL counter statistics view (pg_stat_sql)  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список pgsql-hackers
Peter Eisentraut wrote:

> How about having the tag not be a column name but a row entry.  So you'd
> do something like
> 
> SELECT * FROM pg_stat_sql WHERE tag = 'ALTER VIEW';
> 
> That way, we don't have to keep updating (and re-debating) this when new
> command types or subtypes are added.  And queries written for future
> versions will not fail when run against old servers.

Yeah, good idea.

Let's also discuss the interface from the stats collector.  Currently we
have some 20 new SQL functions, all alike, each loading the whole data
and returning a single counter, and then the view invokes each function
separately.  That doesn't seem great to me.  How about having a single C
function that returns the whole thing as a SRF instead, and the view is
just a single function invocation -- something like pg_lock_status
filling pg_locks in one go.

Another consideration is that the present patch lumps together all ALTER
cases in a single counter.  This isn't great, but at the same time we
don't want to bloat the stat files by having hundreds of counters per
database, do we?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Parallel tuplesort (for parallel B-Tree index creation)
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: PL/Python adding support for multi-dimensional arrays