Message-ID: <623db69f-b40a-4d50-b1bd-bb073fcc4336@tantorlabs.com>
Date: Wed, 5 Feb 2025 13:15:51 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Sample rate added to pg_stat_statements
To: Sami Imseih <samimseih@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>,
 Alena Rybakina <a.rybakina@postgrespro.ru>,
 Alexander Korotkov <aekorotkov@gmail.com>,
 Michael Paquier <michael@paquier.xyz>,
 Greg Sabino Mullane <htamfids@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <fe99e0ca-e564-480e-b865-5f0cee30bc60@tantorlabs.com>
 <CAA5RZ0sBsajHdE_HPoJ-C5rp8QmfArd6a6yJo6bDMVpyW25E+Q@mail.gmail.com>
 <6cf6270b-e8fa-4d99-b74a-17e781cdf309@tantorlabs.com>
 <b40b76c3-fc54-4f11-a50f-e63cd6434560@postgrespro.ru>
 <3a27c830-b81f-4560-9774-a87d9b922fbd@tantorlabs.com>
 <CAA5RZ0vYu+dm3KKd5iaQ=LY0J2sjfxJG+-VCfkeVtWFuhSb-4A@mail.gmail.com>
 <cebfee9c-a894-46f1-b6bc-5bf4a0753b41@tantorlabs.com>
 <7AD765EF-14DE-4B3E-8282-E82A9B44DBAA@yandex-team.ru>
 <e738eac5-ad4d-454c-a079-38766e32ce52@tantorlabs.com>
 <CAA5RZ0s+khQ_u84qS_cAHzxVQQHK_UmWXxRBWTTex7zW1250tQ@mail.gmail.com>
 <0c7770bd-9750-4200-a472-bdb262583c2f@tantorlabs.com>
 <CAA5RZ0vxn_UiUkUK5SdngObLZzw40RhafB7SHydxzBw2_xjjiA@mail.gmail.com>
 <cc1beb52-3e4e-4866-8c32-a5967b98c977@tantorlabs.com>
 <18631d46-1741-4edc-b116-8d9631cdf919@tantorlabs.com>
 <4f98ec33-c627-4eb4-84f3-9994a0982277@tantorlabs.com>
 <CAA5RZ0tJjrX6YiQVDZCOA_BDMuhO-po_T8a3PmjxEEH_iL-qMg@mail.gmail.com>
Content-Language: en-US
From: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
In-Reply-To: <CAA5RZ0tJjrX6YiQVDZCOA_BDMuhO-po_T8a3PmjxEEH_iL-qMg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/623db69f-b40a-4d50-b1bd-bb073fcc4336%40tantorlabs.com>
Precedence: bulk


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@EX13D05UWC001.ant.amazon.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.