On Fri, Aug 15, 2025 at 03:54:29PM -0500, Nathan Bossart wrote:
> On Fri, Aug 15, 2025 at 03:25:20PM -0500, Nathan Bossart wrote:
>> On Fri, Aug 15, 2025 at 04:13:30PM -0400, Andres Freund wrote:
>>> IMO, the only way to actually make pg_stat_statements scale is to move to a
>>> model much more like our regular stats. I.e. accumulate counters in backend
>>> local memory and only occasionally update the shared stats.
>>
>> Agreed. I remember discussing something similar at pgconf.dev this year.
>
> BTW I'm planning to give this a try...
This means to use the pluggable pgstats API to achieve that. FWIW,
one difficulty I am foreseeing is how we want to cap and control the
number of PGSS entries that are saved in the pgstats hash table, based
on the current max PGSS can be set to. Just saying that we'll most
likely rely on a separate zone of shared memory to track this
information. Most of that should happen in the flush callback, based
on the current infra in place, I guess.
More stats are good to have, still capping them is key to keep the
backend under control, and it does not make sense to me to use a fixed
chunk of shared memory for this side (meaning a fixed-sized pgstats
kind for PGSS). Another benefit is to make the max reloadable.
--
Michael
