"Aaron J. Seigo" wrote:
>
> On Mon, 25 Oct 1999, Tim Holloway wrote:
> > hal Lynch wrote:
> > > Is it possible that someday there will be a need for more than 99 "items"
> > > in log classes 1-9?
> > >
> > > hal
> > >
> > > ************
> >
> > Um. I hope not. I was hoping for an admin aid, not a core dump. In any event,
> > a log code is essentially a routing aid. All I can say is that it was enough
> > for http, for whatever that's worth.
>
> a web server doesn't have nearly the user interaction a database has. in a
> database environment i can see the very real _possibility_ of there being 100+
> codes under "User-related Information", especially over time as old events
> become obsolete and new ones are created... in a quick count of user function
> in the Postgrs User's Manual, i counted over 50 unique user functions.
> if each of these is assigned an id, that's over half our space used already!
> will we use those other <50 numbers?
>
> it would be a shame to underallocate a numberspace now when we don't have to
> face breaking anything (e.g. log parsers) than later on when we would. numbers
> are cheap. at the begining anyhow.
>
> --
> Aaron J. Seigo
> Sys Admin
>
> ************
I think you may have crossed the line that separates logging from debugging.
Long before you run out of unique message IDs, you'd probably run out of patience
trying to set up all those hundreds of unique table types (assuming you log
to a database). If you attempted to turn every last detail into a unique field,
just a SELECT statement and its endless variations would be a major nightmare.
As it stands, I have only one code for SELECT, and if I want details, I look at the
statement text itself.
Not to mention that I only have about 50 unique format codes available in the current
scheme.
As an administrator, I want to be able to see what commands are being issued, and
I want to see what the bottom-line consequences are, but I'm really only interested
in the intermediaries to the degree that they affect performance. If I log to that
level of detail, logging ITSELF is likely to impact performance!
Regards,
Tim Holloway
************
