Re: suggestion: log_statement = sample

In response to "Greg Sabino Mullane" <greg(at)turnstep(dot)com>:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> >> In my experience, I've found that enabling full logging for a short time
> >> (perhaps a few hours) gathers enough data to run through tools like
> >> pgFouine and find problem areas.
>
> > 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?

> > But you dont run the real use cases with automated tests. There so many
> > factors involved in real time: caching, concurrency, data, peaktime,
> > deadlocks, doubleclicks, robots etc. that you just can't reproduce it on a
> > development system without lots of effort.

Logging a sample query every arbitrary number of queries isn't a real use
case either, thus your counter argument makes no sense.

I suggested the test system because it's a good compromise.

> >> Additionally, we make
> >> sure our production systems have enough hardware behind them that we can
> >> add additional tasks without it affecting production use.
>
> > that's nice, but not everybody can afford it. Of course i would love to log
> > every statement. But do you really log every statement in production? I guess
> > not.

Try reading my responses instead of guessing. We run full query logging on
occasion to get a sample of real usage on our production systems. As a
result, we know that our servers can handle the load. We're working on
the infrastructure to manage the amount of data so we can do it all the
time (we don't currently have enough disk space).

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.

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/