Re: four minor proposals for 9.5

2014-04-17 7:12 GMT+02:00 Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>:

> On Mon, Apr 14, 2014 at 6:27 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> > 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.
>
> Can't we think of some infrastructure similar to what is done for
> log_duration and log_min_duration_statement?
> Current it prints like below:
> LOG: duration: 343.000 ms statement: create table t1(c1 int);
>
> Let us say if user wants to track lock wait time a statement has
> spent, then enable some config parameter (either log_lock_duration
> or some other convenient way)
>
> LOG: lock duration: 'x' ms statement: create table t1(c1 int);
>

isn't it log_line_prefix analogy?

We can introduce new feature without hard dependency on CSV format

I am thinking so there are clean requests:

simply parseable - vector of numbers is ideal
simply activated, deactivated - maybe list of flags in GUC

Regards

Pavel

>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>