Re: four minor proposals for 9.5

2014-04-14 14:57 GMT+02:00 Robert Haas <robertmhaas(at)gmail(dot)com>:

> On Tue, Apr 8, 2014 at 12:34 PM, Gregory Smith <gregsmithpgsql(at)gmail(dot)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
>