Re: New SQL counter statistics view (pg_stat_sql) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: New SQL counter statistics view (pg_stat_sql)
Date
Msg-id 20160921170524.GA897790@alvherre.pgsql
Whole thread Raw
In response to Re: New SQL counter statistics view (pg_stat_sql)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: New SQL counter statistics view (pg_stat_sql)
Re: New SQL counter statistics view (pg_stat_sql)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Dave Cramer
Date:
Subject: Re: PL/Python adding support for multi-dimensional arrays