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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
