Do you mean stats_command_string? I have seen degradation in using that and am working on a patch for 8.2 to fix it.
--------------------------------------------------------------------------- Marcin wrote: > Qingqing Zhou wrote: > > A similar problem was reported before: > > > > http://archives.postgresql.org/pgsql-admin/2005-12/msg00266.php > > > > But we conclude that's not related to pgstats. See if that's related to > > your situation. > > Unfortunately, I don't think so. The 8.0.3 run just fine. And I don't > see any pgsql_tmp files. The problems started after migration to 8.1.2. > I posted to pgsql-bugs, following Tom suggestion. > BTW, I made some benchmarks on test machine (which is 32bit 2xPIII > 1.4GHz) with pgbench and I was quite amazed: > pgbench -S -c 50 -t 10000 -v pgbench > with stats collector disabled resulted in: > tps = 3178.346439 (including connections establishing) > tps = 3183.360731 (excluding connections establishing) > > with stats collector enabled, but stats_command_prompt disabled: > tps = 3143.376908 (including connections establishing) > tps = 3147.564695 (excluding connections establishing) > > and with stats_command_prompt enabled: > tps = 2446.136610 (including connections establishing) > tps = 2448.785260 (excluding connections establishing) > > However, I didn't notice any suspicious write activity. > > Thanks for suggestion, > -- > Marcin > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
