I seem to recall a discussion, perhaps in-person, around the time Theo submitted that patch where it was reported that the logging collector could not be used on some systems he was working with because it became a major performance bottleneck. With each backend writing its own messages to a file, it was tolerable, but when you tried to funnel everything through a single process, the back-pressure slowed down the entire system unacceptably.
Finally found myself back at this one, because I still think this is a problem we definitely need to adress (whether with this file or not).
The funneling into a single process is definitely an issue.
But we don't really solve that problem today wit logging to stderr, do we? Because somebody has to pick up the log as it came from stderr. Yes, you get more overhead when sending the log to devnull, but that isn't really a realistic scenario. The question is what to do when you actually want to collect that much logging that quickly.
If each backend could actually log to *its own file*, then things would get sped up. But we can't do that today. Unless you use the hooks and build it yourself.
Per the thread referenced, using the hooks to handle the very-high-rate-logging case seems to be the conclusion. But is that still the conclusion, or do we feel we need to also have a native solution?
And if the conclusion is that hooks is the way to go for that, then is the slowdown of this patch actually a relevant problem to it?
