On Tue, 20 Feb 2007, Tom Lane wrote:

A smaller problem is that this forces people to incur a gettimeofday
call for every message logged


I'm stumped trying to think of an application that would require importing the logs into a database to analyze them, but not need the timestamp. I'd expect it to be the primary key on the data.

Is it worth providing a knob to determine the set of columns emitted?

Myself and Guillaume felt that having the format be standardized had significant value from a downstream application perspective; it would be nice to know that everyone can work together to write one simple tool chain to process these things and it would work everywhere. The current level of log output customization is part of what makes log analysis tools so much of a pain.

How about this as a simple way to proceed: have the patch include everything, as Arul already planned. When it's done, do some benchmarking with it turned on or off. If it really seems like a drag, then consider a GUC addition to trim it down. Why optimize prematurely? It's not like this will be on by default. My guess is that the person sophisticated to analyze their logs probably has an installation that can support the overhead.

--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to