|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: New SQL counter statistics view (pg_stat_sql)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
|Next Message||Dave Cramer||2016-09-21 17:53:41||Re: PL/Python adding support for multi-dimensional arrays|
|Previous Message||Heikki Linnakangas||2016-09-21 16:52:00||Re: Parallel tuplesort (for parallel B-Tree index creation)|