| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Robert Treat <rob(at)xzilla(dot)net>, satyanarlapuram(at)gmail(dot)com, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, tndrwang(at)gmail(dot)com |
| Subject: | Re: Add pg_stat_autovacuum_priority |
| Date: | 2026-04-08 21:33:00 |
| Message-ID: | CAA5RZ0uL1ukKvV0Gwgok9ut_203q_E_tzBrwhDAuJCKVNwWZVw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On Wed, Apr 08, 2026 at 04:40:03PM -0400, Andres Freund wrote:
> > Note that the whole cached state does automatically get reset at the end of
> > the transaction (AtEOXact_PgStat()->pgstat_clear_snapshot()), just like it did
> > before the shmem stats stuff.
>
> I see a lot of memory used for the pgStatEntryRefHash table, too (e.g., ~16
> MB for 100K tables). What's interesting is that I cannot reproduce similar
> usage with views like pg_stat_all_tables. If memory was not a concern, I
> think the "bool *may_free" idea would be fine.
Instead of may_free, which is invasive, what about pgstat_fetch_entry_nocache
which can be called by 2 new APIs pgstat_fetch_stat_tabentry_nocache() and
pgstat_fetch_stat_tabentry_nocache_ext(). This way a caller that uses
these will be required to pfree?
This will allow us to also avoid the GUC override as well in autovacuum.c.
--
Sami
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-04-08 21:48:31 | Re: Add pg_stat_autovacuum_priority |
| Previous Message | Peter Geoghegan | 2026-04-08 21:30:21 | Re: s/pg_attribute_always_inline/pg_always_inline/? |