Re: contrib/pg_stat_statements v2

Hello,<br /><br />I have two concerns regarding the patch:<br /><br />A) I am not sure if it is good to have a single
contentionpoint (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
tosplit pgss->lock into several ones to reduce contention on it.<br /><br />B) I really do not like the idea of
ResetBufferUsage.<br/><br />I do vote for eliminating ResetBufferUsage from the sources (even from the core sources)<br
/>Thereason is as follows:<br />   1) No one really tries to reset "current timestamp" counter. Why do we reset buffer
usageevery now and then?<br />    2) As new call sites of ResetBufferUsage appear it becomes more likely to fetch
"wrong"statistics from that counters due to "accidental" reset.<br />   3) When it comes to fetch "buffer usage", one
mightuse the same approach as with timings: calculate the difference between two measurements. I do not believe it is
noticeablyslower than reset+measure.<br /><br />I wish PostgreSQL had some kind of pg_session_statistics view that
reportsresource usage statistics for each session.<br />For instance, it could expose "buffer usage" to the client, so
itcould get more details on resource usage. For instance, I would like to see a new tab in pgAdmin that shows "total
numberof buffer gets", "number of WAL records created", "number of rows sorted" and similar information after query
finishes(even in plain "execute" mode).<br /> 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,
computesthe difference and plots it on a graph.<br /><br />Sincerely,<br />Vladimir Sitnikov<br />