| From: | Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org> |
| Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal: roll pg_stat_statements into core |
| Date: | 2019-09-02 08:11:28 |
| Message-ID: | a14c6de1-4c4c-8af8-cdd2-b728c06f6518@anayrat.info |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
1: https://twitter.com/AndresFreundTec/status/1105585237772263424
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2019-09-02 08:38:56 | Re: pg_basebackup -F t fails when fsync spends more time than tcp_user_timeout |
| Previous Message | r.takahashi_2@fujitsu.com | 2019-09-02 08:06:22 | RE: pg_basebackup -F t fails when fsync spends more time than tcp_user_timeout |