Re: Proposal: roll pg_stat_statements into core - Mailing list pgsql-hackers

From Adrien Nayrat
Subject Re: Proposal: roll pg_stat_statements into core
Date
Msg-id a14c6de1-4c4c-8af8-cdd2-b728c06f6518@anayrat.info
Whole thread Raw
In response to Re: Proposal: roll pg_stat_statements into core  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal: roll pg_stat_statements into core
List 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




Attachment

pgsql-hackers by date:

Previous
From: "r.takahashi_2@fujitsu.com"
Date:
Subject: RE: pg_basebackup -F t fails when fsync spends more time thantcp_user_timeout
Next
From: Michael Paquier
Date:
Subject: Re: pg_basebackup -F t fails when fsync spends more time thantcp_user_timeout