From: | Janning Vygen <vygen(at)kicktipp(dot)de> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: suggestion: log_statement = sample |
Date: | 2009-07-21 07:42:11 |
Message-ID: | 200907210942.11250.vygen@kicktipp.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Monday 20 July 2009 19:24:13 Bill Moran wrote:
> > > It is not possible for us. Logging millions of statements take too much
> > > time.
>
> This is a ridiculous statement. In actual practice, full query logging
> is 1/50 the amount of disk I/O as the actual database activity. If your
> systems are so stressed that they can't handle another 2% increase, then
> you've got bigger problems lurking.
>
> Have you benchmarked the load it creates under your workload?
Yes, it takes up to 15% of our workload in an average use case. But we have
peak times where we can not afford 15% lost for logging!
And if we log on the same disk, it slows down reading and writing. So it does
not really matter how much work load it creates. If it slows down my response,
i dont want to log everything. (I know that logging onto the same disk is
bad!)
> Overall, it seems like you've decided that you want this feature and
> nothing else will do. If that's the case, then just go ahead and write it.
It was really just a suggestion. I know that i can handle my problems in a
different way like doing full logging from time to time, better automatic
tests, more hardware and so on. I just thought, it couldnt be so hard to log
every nth statement instead of all. And i think that there are lot of
usescases out there for a directive like this. I really just wanted to help to
make postgresql better. Even if it would be implemented soon, it wouldn't help
me. As i need to analyze my load now!
kind regards
Janning
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Sergio Borgonovo | 2009-07-21 08:21:15 | checking for temp tables information_schema vs. EXCEPTION |
Previous Message | Daniel Verite | 2009-07-21 07:37:04 | Re: Best practices for moving UTF8 databases |