Em seg, 2 de set de 2019 às 05:11, Adrien Nayrat <adrien.nay...@anayrat.info> escreveu: > > On 9/1/19 8:54 PM, Tom Lane wrote: > >> - The overhead for most use cases is low compared to the benefit. > > Please do not expect that we're going to accept such assertions > > unsupported by evidence. (As a very quick-n-dirty test, I tried > > "pgbench -S" and got somewhere around 4% TPS degradation with > > pg_stat_statements loaded. That doesn't seem negligible.) > > AFAIR Andres pointed overhead could be much more when you have more queries > than > pg_stat_statements.max [1]. Eviction can be costly. > pg_stat_statements is important in a lot of query analysis. If you make a comparison between pg_stat_statements and pgbadger, you can capture queries for the latter changing log_min_duration_statement or log_statement without restart the server, however, the former you can't without restarting the server. At least if pg_stat_statements was in core you could load it by default and have a GUC to turn it on/off without restarting the server (that was Magnus proposal and Andres agreed). I support this idea. In v10 we changed some GUCs to perform replication out-of-box; we should do the same for query analysis.
Regards, -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
