Michael Fuhr <mike@xxxxxxxx> writes: > Further tests show that for this application > the killer is stats_command_string, not stats_block_level or > stats_row_level. I tried it with pgbench -c 10, and got these results: 41% reduction in TPS rate for stats_command_string 9% reduction in TPS rate for stats_block/row_level (any combination) strace'ing a backend confirms my belief that stats_block/row_level send just one stats message per transaction (at least for the relatively small number of tables touched per transaction by pgbench). However stats_command_string sends 14(!) --- there are seven commands per pgbench transaction and each results in sending a <command> message and later an <IDLE> message. Given the rather lackadaisical way in which the stats collector makes the data available, it seems like the backends are being much too enthusiastic about posting their stats_command_string status immediately. Might be worth thinking about how to cut back the overhead by suppressing some of these messages. regards, tom lane
