Re: Separate memory contexts for relcache and catcache - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Separate memory contexts for relcache and catcache
Date
Msg-id 8299a41d01f78e939f2c36d383cea1fe7d77227f.camel@j-davis.com
Whole thread Raw
In response to Re: Separate memory contexts for relcache and catcache  (Andres Freund <andres@anarazel.de>)
Responses Re: Separate memory contexts for relcache and catcache
Re: Separate memory contexts for relcache and catcache
List pgsql-hackers
On Fri, 2024-11-01 at 15:19 -0400, Andres Freund wrote:
> I'm a bit worried about the increase in "wasted" memory we might end
> up when
> creating one aset for *everything*. Just splitting out Relcache and
> CatCache
> isn't a big deal from that angle, they're always used reasonably
> much. But
> creating a bunch of barely used contexts does have the potential for
> lots of
> memory being wasted at the end of a page and on freelists.  It might
> be ok as
> far was what you proposed in the above email, I haven't analyzed that
> in depth
> yet.

Melih raised similar concerns. The new contexts that my patch created
were CatCacheContext, RelCacheContext, SPICacheContext,
PgOutputContext, PlanCacheContext, TextSearchCacheContext, and
TypCacheContext.

Those are all created lazily, so you need to at least be using the
relevant feature before it has any cost (with the exception of the
first two).

> > I agree with others that we should look at changing the initial
> > size or
> > type of the contexts, but that should be a separate commit.
>
> It needs to be done close together though, otherwise we'll increase
> the
> new-connection-memory-usage of postgres measurably.

I don't have a strong opinion here; that was a passing comment. But I'm
curious: why it would increase the per-connection memory usage much to
just have a couple new memory contexts?

> I've previously proposed creating a type of memory context that's
> intended for
> places where we never expect to allocate much which allocates from
> either a
> superior memory context or just from the system allocator and tracks
> memory
> via linked lists.

Why not just use ALLOCSET_SMALL_SIZES?


Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Count and log pages set all-frozen by vacuum
Next
From: Tom Lane
Date:
Subject: Re: Using Expanded Objects other than Arrays from plpgsql