Re: contrib/pg_stat_statements v2

Hello,

I have two concerns regarding the patch:

A) I am not sure if it is good to have a single contention point (pgss->lock
= LWLockAssign()). I guess that would impact scalability, especially on a
multi-cpu systems. I guess the real solution will come when PostgreSQL have
a pool for sql statements, hovewer it could make sense to split pgss->lock
into several ones to reduce contention on it.

B) I really do not like the idea of ResetBufferUsage.

I do vote for eliminating ResetBufferUsage from the sources (even from the
core sources)
The reason is as follows:
1) No one really tries to reset "current timestamp" counter. Why do we
reset buffer usage every now and then?
2) As new call sites of ResetBufferUsage appear it becomes more likely to
fetch "wrong" statistics from that counters due to "accidental" reset.
3) When it comes to fetch "buffer usage", one might use the same approach
as with timings: calculate the difference between two measurements. I do not
believe it is noticeably slower than reset+measure.

I wish PostgreSQL had some kind of pg_session_statistics view that reports
resource usage statistics for each session.
For instance, it could expose "buffer usage" to the client, so it could get
more details on resource usage. For instance, I would like to see a new tab
in pgAdmin that shows "total number of buffer gets", "number of WAL records
created", "number of rows sorted" and similar information after query
finishes (even in plain "execute" mode).
The second application of that statistics could be server health monitoring:
provided there is an interface for ongoing integral statistics, one could
create a job that takes snapshots, computes the difference and plots it on a
graph.

Sincerely,
Vladimir Sitnikov