Re: Separate memory contexts for relcache and catcache

From: Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, andres(at)anarazel(dot)de, vignesh C <vignesh21(at)gmail(dot)com>
Subject: Re: Separate memory contexts for relcache and catcache
Date: 2024-10-31 13:58:19
Message-ID: CAGPVpCTLx=dD0xvapV5UBgLHLt6A=vCyrcXRCSpUW7npYibWZw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Jeff,

Jeff Davis <pgsql(at)j-davis(dot)com>, 30 Eki 2024 Çar, 01:00 tarihinde şunu yazdı:

> On Wed, 2024-04-03 at 16:12 +0300, Melih Mutlu wrote:
> > Rebased. PSA.
>
> Thank you. I missed your patch and came up with a similar patch over
> here:
>
>
> https://www.postgresql.org/message-id/flat/78599c442380ddb5990117e281a4fa65a74231af(dot)camel(at)j-davis(dot)com
>
> I closed my thread and we can continue this one.
>

Thanks for being interested in this patch. I simply merged your patch and
mine, which was pretty easy as your patch is quite similar to mine but
covers much more caches.

One difference is that I tried to capture almost all uses of
> CacheMemoryContext so that it would become just a parent context
> without many allocations of its own.
>
> The plan cache and SPI caches can be important, too. Or, one of the
> other caches that we expect to be small might grow in some edge cases
> (or due to a bug), and it would be good to be able to see that.
>

My only concern would be allocating too much memory for each cache
type unnecessarily. Especially the ones that are expected to be small most
of the time, would we see cases where we waste too much memory when the
number of backends increases? Or maybe having separate contexts for each
cache wouldn't hurt at all. I don't really have enough knowledge about each
cache type.

I only quickly checked the memory usage right after starting a backend to
ensure that the patch does not slow down backend starts. We now have an
additional TypCacheContext, which was previously using CacheMemoryContext,
with 8KB init size. I'm not sure how much we should be worried about this
additional 8KB. I think we can reduce the initial size of
CacheMemoryContext instead,
assuming that CacheMemoryContext wouldn't have many allocations of its own
anymore.

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.
>

Attached a separate patch to change initial sizes for relcache and catcache
contexts as they grow large from the start. This was suggested in the
thread previously [1].
Also changed CacheMemoryContext to use ALLOCSET_START_SMALL_SIZES, so it
starts from 1KB.

Regards,
--
Melih Mutlu
Microsoft

Attachment Content-Type Size
v4-0002-Adjusting-cache-memory-context-sizes.patch application/octet-stream 1.7 KB
v4-0001-Separate-memory-contexts-for-caches.patch application/octet-stream 49.6 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2024-10-31 14:00:02 Re: Inval reliability, especially for inplace updates
Previous Message Corey Huinker 2024-10-31 13:52:12 Re: Statistics Import and Export