Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I think they fit pretty nicely on one line, and lot of folks want that
> > information. I realize it looks like bloatware because it duplicates
> > some existing functionality, but I think it is a combination of duration
> > and statement output that can't be done easily separately.
>
> Sure it can. You're essentially arguing that DBAs are too dumb to match
> up matching query and duration log outputs. I don't buy that. I think
> they'll be analyzing their logs with little Perl scripts anyway, and
> that consistency of log output format will be worth more to those
> scripts than sometimes having related items all on one log line.
Yes, I am arguing that we shouldn't make people jump through Perl hoops
to get a statement/duration line in their log files. I think it is
asked for enough that a nice printed line will help them.
If we already have the parameter, why not make it easy. If they are
using Perl, they can already use log_statement and log_duration to print
only queries taking over a certain amount of time.
> >> BTW, there's a separate set of problems that have yet to be addressed,
> >> which is how any of these logging options apply for V3-protocol query
> >> operations. The existing code only seems to work for the old-style
> >> query path.
>
> > You mean how are they passed to the client? I assumed that would work
> > for pre-V3 clients.
>
> No, I mean the functionality isn't in the extended-query code path at
> all, and it's not immediately clear where to insert it (eg, which steps
> of parse/bind/execute do what logging, or where you measure duration).
I assume it would be all executor stuff, but I see what you mean that
the perpare isn't going through the normal query path.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
