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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers