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

From Melih Mutlu
Subject Re: Separate memory contexts for relcache and catcache
Date
Msg-id CAGPVpCQqAbBNaFQ7YiTnF5ug2uGxK-HQBMofh1QT9JQQB3Bu8g@mail.gmail.com
Whole thread Raw
In response to Re: Separate memory contexts for relcache and catcache  (torikoshia <torikoshia@oss.nttdata.com>)
Responses Re: Separate memory contexts for relcache and catcache
List pgsql-hackers
Hi,

torikoshia <torikoshia@oss.nttdata.com>, 4 Ara 2023 Pzt, 07:59 tarihinde şunu yazdı:
Hi,

I also think this change would be helpful.

I imagine you're working on the Andres's comments and you already notice
this, but v1 patch cannot be applied to HEAD.
For the convenience of other reviewers, I marked it 'Waiting on Author'.

Thanks for letting me know. I rebased the patch. PFA new version.




Andres Freund <andres@anarazel.de>, 12 Eki 2023 Per, 20:01 tarihinde şunu yazdı:
Hi,

Have you checked what the source of the remaining allocations in
CacheMemoryContext are?

It's mostly typecache, around 2K. Do you think typecache also needs a separate context?

Given the size of both CatCacheMemoryContext and RelCacheMemoryContext in a
new backend, I think it might be worth using non-default aset parameters. A
bit ridiculous to increase block sizes from 8k upwards in every single
connection made to postgres ever.

Considering it starts from ~262K, what would be better for init size? 256K?  

> +static void
> +CreateCatCacheMemoryContext()

We typically use (void) to differentiate from an older way of function
declarations that didn't have argument types.
Done. 

> +{
> +     if (!CacheMemoryContext)
> +             CreateCacheMemoryContext();

I wish we just made sure that cache memory context were created in the right
place, instead of spreading this check everywhere...

That would be nice. Do you have a suggestion about where that right place would be?

I'd just delete these comments, they're just pointlessly restating the code.

Done.

Thanks,
--
Melih Mutlu
Microsoft
Attachment

pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: remaining sql/json patches
Next
From: Bertrand Drouvot
Date:
Subject: Re: Synchronizing slots from primary to standby