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