Josh Berkus wrote:
Tom,


Another relevant question is why you are expecting to get this
information through pgstats and not by looking in the postmaster log.
I don't know about you, but I don't have any tools that are designed to
cope nicely with looking at tables that have columns that might be many
K wide.  Looking in the log seems a much nicer way of examining the full
text of extremely long queries.  So I think it's actually a good thing
that pgstats truncates the queries at some reasonable width.


Because pg_stat_activity can be queried dynamically, and the log can't.

I've been planning to post a lengthy mail after 8.0 release, but it seems a good idea to do it now.


When comparing pgsql to MSSQL in practice, I encounter a similar problem as Josh. I got a server hammered by countless queries, some of them not too well constructed and thus soaking CPU from all users. On MSSQL, I'd be using the Profiler, which lets me tap one or more connections, and log whatever I think is important to trace down the problem. This lets me filter out those uninteresting 99.9 % of queries which would make my log unreadable. Additionally, some performance measures are recorded for each query, enabling me to spot the bad guys, analyze and improve them.

On pgsql, all logging goes unstructured into one file, I even can't start and stop a new log on demand on my observation period (somebody refused to implement a manual log rotation function, "nobody needs that"...) On a server addressed by 100 users, with several dozens of queries fired every second, it's hard work to locate the offending query.

It appears to me that simple increasing the max query length won't do the deal (and 16k would not be enough). What I'd like to see is the possibility to tap one or more backends (this is superuser only, of course), and put them in a logging mode, which will record the complete query including performance counters to some process in a lossless way. When I say tapping I mean that the backend configuration switch is *not* set by the very same backend, but from a different superuser backend.

Regards,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to