add pg_stat_statements metrics

[tmc]

This incorporates pg_stat_statements in the example additional queries.

[wrouesnel]

Could you rebase this? Also, do you think this would be a good candidate for being made an internal metric (how expensive is this query, basically)?

[ivan-kiselev]

Pay attention to this PR please, we also need this functionality in our monitoring system.

[databus23]

I think this description is a copy & paste typo

[databus23]

And also doesn't really sound right. Should be "Name of the database"

[coveralls]

Coverage remained the same at 51.391% when pulling 682a12e on tmc:master into 53b9d9c on wrouesnel:master.

[coveralls]

Coverage remained the same at 51.815% when pulling 90fbacf on tmc:master into 1fa394d on wrouesnel:master.

[coveralls]

Coverage remained the same at 51.815% when pulling 491db5e on tmc:master into 1fa394d on wrouesnel:master.

[sharmay]

FYI, requires pg_stat_statements so to be loaded via shared_preload_library statement.

[uspen]

May be so:

SELECT coalesce(d.datname, '~unknown') AS database, coalesce(r.rolname, '~unknown') AS user, s.query, s.calls, s.total_time, s.min_time, s.max_time, s.mean_time, s.stddev_time, s.rows, s.shared_blks_hit, s.shared_blks_read, s.shared_blks_dirtied, s.shared_blks_written, s.local_blks_hit, s.local_blks_read, s.local_blks_dirtied, s.local_blks_written, s.temp_blks_read, s.temp_blks_written, s.blk_read_time, s.blk_write_time FROM pg_stat_statements s JOIN pg_roles r ON r.oid=s.userid JOIN pg_database d ON d.oid=s.dbid WHERE d.datname NOT IN ('postgres', 'template0', 'template1') AND s.calls > 100

[gregscds]

This pull request says "add pg_database_size metric", but what it actually does is use a view from the pg_stat_statements extension. I can't tell whether the votes for this pull were based on its description (database size) or its actual function (statement statistics)
.
Supporting statements statistics correctly is a lot more work than just adding this query. pg_stats_statements may not be loaded. Also, that extension been actively in development where the fields available depends heavily on which version of PostgreSQL you're running.

I would suggest closing this pull because it can't just be coded and merged this easily. Then a proper issue for pg_stats_statements should be opened to work out how to handle the tricky bit of version specific work.

[coveralls]

Coverage remained the same at 50.801% when pulling ce5826a on tmc:master into 81194c9 on wrouesnel:master.

[wrouesnel]

@gregscds Thanks for the analysis. It does raise the bigger issue of how that queries.yaml file included in the repo should be supported. I suspect it needs to evolve towards being a bundle of examples that can be dropped in by users - since its perfect for site-specific extra metrics.

[strangeman]

Got fatal error: runtime: out of memory with queries.yaml from that PR: https://pastebin.com/qVmrwYUj
BTW, with queries.yaml from the current master all working correctly.

[coveralls]

Coverage remained the same at 54.135% when pulling 3b26962 on tmc:master into 6e3d130 on wrouesnel:master.

[coveralls]

Coverage remained the same at 59.476% when pulling 69b216e on tmc:master into 27d5c99 on wrouesnel:master.

[tmc]

I've looped around at another job and now I want this again.

[binakot]

What news with this request? 🐘

[mbanck]

The queryid column is present in all supported versions of Postgres (i.e. in 9.4+), so maybe nowadays it would make sense to add it as LABEL in order to avoid issues like in #219 (comment)

[wrouesnel]

Than you all for comments on this, this has lingered long enough. I've fixed the original issues and re-issued it as a new PR.

[mbanck]

I still think exposing the queryid column is a good idea, even more so now that 0.6.0+ requires Postgres 9.4+ anyway and it will always be present.

Otherwise, people risk getting "collected metric ... was collected before with the same name and label values" errors from Prometheus for the 'insufficient privileges' case as query content.