Re: four minor proposals for 9.5

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: four minor proposals for 9.5
Дата
Msg-id CAFj8pRAPF5y4RnnfFB8pTTgAa_vz=20NFt5Oxj3taktQMFGYWA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: four minor proposals for 9.5  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: four minor proposals for 9.5  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers



2014-04-14 14:57 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:
On Tue, Apr 8, 2014 at 12:34 PM, Gregory Smith <gregsmithpgsql@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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Including replication slot data in base backups
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Patch: add psql tab completion for event triggers