2014-04-14 14:57 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > On Tue, Apr 8, 2014 at 12:34 PM, Gregory Smith <gregsmithpg...@gmail.com> > wrote: > > On 4/6/14 2:46 PM, Pavel Stehule wrote: > >> Proposed options are interesting for "enterprise" using, when you have a > >> some more smart tools for log entry processing, and when you need a > complex > >> view about performance of billions queries - when cancel time and lock > time > >> is important piece in mosaic of server' fitness. > > > > I once sent a design proposal over for something I called "Performance > > Events" that included this. It will be difficult to get everything > people > > want to track into log_line_prefix macro form. You're right that this > > particular one can probably be pushed into there, but you're adding four > > macros just for this feature. And that's only a fraction of what people > > expect from database per-query performance metrics. > > I agree. I don't think the idea of pushing this into the > log_line_prefix stuff as a one-off is a very good one. Sure, we could > wedge it in there, but we've got an existing precedent that everything > that you can get with log_line_prefix also shows up in the CSV output > file. And it's easy to imagine LOTS more counters that somebody might > want to have. Time spent planning, time spent executing, time spent > waiting for disk I/O, time spent returning results to client, and I'm > sure people will think of many others. I think this will balloon out > of control if we don't have a more systematic design for this sort of > thing. >
I am thinking about this feature - and it has a more dimensions 1. In context of relation databases I am thinking so query duration, and query lock time are relative basic metric and then should be in log_line_prefix 2. I can imagine, so someone would to monitor a lot of metric on query level - and we should to provide some method how to do it. log_line_prefix should be or should not be solution. Any log_line_prefix like solution can be useful. Do you have some idea about future direction of PostgreSQL logging? Requests: a) possibility to choose a format: CSV, JSON, XML b) possibility to choose a set of metrics: ... c) possibility to choose a target: syslog, file, .. Pavel -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
