From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sample rate added to pg_stat_statements |
Date: | 2025-02-05 10:15:51 |
Message-ID: | 623db69f-b40a-4d50-b1bd-bb073fcc4336@tantorlabs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 04.02.2025 20:59, Sami Imseih wrote:
>> To summarize the results of all benchmarks, I compiled them into a table:
> Thanks for compiling the benchmark data above.
>
> The main benefit of this patch will be to give the user
> a toggle if they are observing high spinlock contention
> due to pg_stat_statements which will likely occur
> on larger machines.
>
> I also did not see this thread [1] mentioned in the thread above,
> but one of the reasons pg_stat_statements.track_planning
> was turned off by default was due to the additional spinlock
> acquire to track the planning stats. Bringing this up as sample_rate
> might also be beneficial as well if a user decides to track planning.
>
> Regards,
>
> Sami
>
> [1] https://www.postgresql.org/message-id/flat/2895b53b033c47ccb22972b589050dd9(at)EX13D05UWC001(dot)ant(dot)amazon(dot)com
Thanks for the thread. As we can see, simply enabling or disabling not
only track_planning but also other pg-stat_statements parameters is too
radical a measure for managing performance. With the introduction of
sample_rate, users now have more flexibility in controlling spinlock
contention. This allows them to balance overhead and statistics
collection rather than completely disabling the feature.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2025-02-05 10:22:55 | Re: per backend WAL statistics |
Previous Message | Michail Nikolaev | 2025-02-05 10:11:40 | Re: Why doesn't GiST VACUUM require a super-exclusive lock, like nbtree VACUUM? |