Search Postgresql Archives

Re: suggestion: log_statement = sample

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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.

Too much time to do what? Where is the bottleneck?

> 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.                                 

Agreed.

>> 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.                                                                          

We have clients that do, and we always recommend it for all of our clients. It
can get very expensive (hint: ship them off with syslog over an internal
network to a dedicated box), but being able to see exactly what happened
in your database when something goes wrong after the fact is invaluable.
Plus we can then run tools like pgsi (http://bucardo.org/pgsi/) to get
nice statistics and find weak spots in the application code.

> Again: for my use case it makes sense to have a log_sample feature.

Perhaps, but I don't think you've quite overcome the 'log everything'
counter-argument. I don't think log_sample is necessarily a bad idea, but I
doubt it is going to happen soon, and certainly not in time to put
on your production system in the next year or so. Perhaps you can attack
this from another angle, such as using some sort of filter or script
to grab every X lines from the logs and discard the rest while in
full logging mode. That would have the advantage of being fully
backwards-compatible and usable today.


- --
Greg Sabino Mullane greg@xxxxxxxxxxxx
End Point Corporation
PGP Key: 0x14964AC8 200907201256
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkpkoh4ACgkQvJuQZxSWSsi5swCfSgxE/3Vs+kCmfqSERL6u84XJ
nNQAoO5oOs/Nwuhe27FQ+THZEUVcdULO
=7JPQ
-----END PGP SIGNATURE-----



-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux