As far as I know, more than 10,000 tables of instances are often encountered,
So I insist that the maximum can be appropriately increased to 256MB，Can be more adaptable to many table situations
On Thu, 26 Dec 2024 at 23:23, Robert Treat <rob@xzilla.net> wrote:
On Wed, Dec 25, 2024 at 12:26 PM Tomas Vondra <tomas@vondra.me> wrote: > > Hi, > > On 12/23/24 07:35, wenhui qiu wrote: > > Hi Tomas > > This is a great feature. > > + /* > > + * Define (or redefine) custom GUC variables. > > + */ > > + DefineCustomIntVariable("stats_history.size", > > + "Sets the amount of memory available for past events.", > > + NULL, > > + &statsHistorySizeMB, > > + 1, > > + 1, > > + 128, > > + PGC_POSTMASTER, > > + GUC_UNIT_MB, > > + NULL, > > + NULL, > > + NULL); > > + > > RAM is in terabytes now, the statsHistorySize is 128MB ,I think can > > increase to store more history record ? > > > > Maybe, the 128MB is an arbitrary (and conservative) limit - it's enough > for ~500k events, which seems good enough for most systems. Of course, > on systems with many relations might need more space, not sure. > > I was thinking about specifying the space in more natural terms, either > as amount of time ("keep 1 day of history") or number of entries ("10k > entries"). That would probably mean the memory can't be allocated as > fixed size. >
Based on the above, a rough calculation is that this is enough for holding 1 year of hourly vacuum runs for 50 tables, or a year of daily vacuums for 1000 tables. Most folks will fall somewhere in that range (and won't really need a year's history) but that seems like plenty for a default.
> But maybe it'd be possible to just write the entries to a file. We don't > need random access to past entries (unlike e.g. pg_stat_statements), and > people won't query that very often either. >
Yeah, workloads will vary, but it doesn't seem like they would more than query workloads do.
