Re: New SQL counter statistics view (pg_stat_sql)

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)
Date: 2016-09-21 17:05:24
Message-ID: 20160921170524.GA897790@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
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)