Re: Add pg_stat_autovacuum_priority - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Add pg_stat_autovacuum_priority
Date
Msg-id CAA5RZ0uOENy8Y+UNXpcGvFFHhT_oxYPqa-o0Jv1rOriC6w8VSg@mail.gmail.com
Whole thread
In response to Re: Add pg_stat_autovacuum_priority  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > This sounds most similar to the "bool *may_free" idea that Andres just
> > posted.  IIUC the idea is that callers can free the result if they want,
> > but they aren't required to do so.
>
> Hmm, yeah I suppose a caller that doesn't care about leakage could
> skip the pfree.  But are there really any of those?  The complaint
> that prompted 02502c1bc concerned databases with many many thousands
> of relations.
>
> I now realize that what you said upthread about caching the results
> might be a bigger problem, ie if the pgstats code does retain all
> these values then we'd have a memory bloat problem there.  Maybe
> we need a more aggressive API change that includes a way to specify
> "don't cache this result".

hmm, do you mean an API to override the pgstat_fetch_consistency GUC?

--
Sami



pgsql-hackers by date:

Previous
From: Lukas Fittl
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Andres Freund
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?