Hi,
I rebased and updated the patch to address some concerns raised before and
see if anyone is still interested in this.
I believe that there is a general consensus around RelCacheContext and
CatCacheContext, considering that these two caches are fairly used. For the
rest, I followed Ashutosh's
On Tue, Nov 26, 2024 at 05:11:16PM +0300, Melih Mutlu wrote:
> That said, these changes come with a cost, and it may not be worth it to
> separate every single cache into its own context. IIUC, introducing
> contexts for heavily used caches results in much less fragmentation. If
> that’s the case,
Hi Rahila,
Rahila Syed , 26 Kas 2024 Sal, 13:40 tarihinde şunu
yazdı:
> Observations:
> 1. While there are a number of child contexts like index info of
> RelCacheContext,
>CatCacheContext does not have any children.
> 2. While there is a bunch of used memory in RelCacheContext and
> CatCache
On Tue, Nov 26, 2024 at 4:10 PM Rahila Syed wrote:
>
>
> Having reviewed the discussion regarding potential fragmentation issues
> caused by
> creating a large number of new contexts in each backend, I would like to
> take a step
> back and better understand the motivation behind separating these
Hi Melih, Jeff,
I tested the v4 patch along with the memory statistics reporting patch from
[1] thread.
After running a plpgsql procedure periodically and querying its memory
consumption,
I see various child contexts of CacheMemoryContext created as shown in the
image below or link [2].
[image:
On Tue, Nov 12, 2024 at 2:57 AM Jeff Davis wrote:
>
> On Mon, 2024-11-11 at 17:05 +0530, Ashutosh Bapat wrote:
> > It will be good
> > to move ahead with the ones we all agree for now. Looking at all the
> > emails, those will be CatCacheContext,
> > RelCacheContext, PlanCacheContext, TypCacheCont
On Mon, 2024-11-11 at 17:05 +0530, Ashutosh Bapat wrote:
> It will be good
> to move ahead with the ones we all agree for now. Looking at all the
> emails, those will be CatCacheContext,
> RelCacheContext, PlanCacheContext, TypCacheContext.
I'm not sure we have consensus on all of those yet. Andre
On Sat, Nov 2, 2024 at 4:18 AM Andres Freund wrote:
>
>
> > > 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
On Sat, Nov 2, 2024 at 3:17 AM Jeff Davis wrote:
>
> 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 dea
Hi,
On 2024-11-01 14:47:37 -0700, Jeff Davis wrote:
> 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 de
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
>
Hi,
On 2024-10-29 15:00:02 -0700, Jeff Davis wrote:
> 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.ca.
Hi Jeff,
Jeff Davis , 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/78599c442380ddb5990117e281
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.ca...@j-davis.com
I closed my thread and we can continue this one.
vignesh C , 27 Oca 2024 Cmt, 06:01 tarihinde şunu
yazdı:
> On Wed, 3 Jan 2024 at 16:56, Melih Mutlu wrote:
> CFBot shows that the patch does not apply anymore as in [1]:
> === Applying patches on top of PostgreSQL commit ID
> 729439607ad210dbb446e31754e8627d7e3f7dda ===
> === applying patch
> ./v
On Wed, 3 Jan 2024 at 16:56, Melih Mutlu wrote:
>
> Hi,
>
> torikoshia , 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
Hi,
torikoshia , 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 'Wai
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'.
--
Regards,
--
Atsushi Torikoshi
NTT DATA Group Corpo
Hi,
On 2023-08-09 15:02:31 +0300, Melih Mutlu wrote:
> To quickly show how pg_backend_memory_contexts would look like, I did the
> following:
>
> -Create some tables:
> SELECT 'BEGIN;' UNION ALL SELECT format('CREATE TABLE %1$s(id serial
> primary key, data text not null unique)', 'test_'||g.i) F
On Thu, 10 Aug 2023 at 01:23, Alvaro Herrera wrote:
>
> On 2023-Aug-09, Melih Mutlu wrote:
>
> > --Patch
> > name | used_bytes | free_bytes | total_bytes
> > ---+++-
> > RelCacheMemoryContext |4706464 |3682144 |
On 2023-Aug-09, Melih Mutlu wrote:
> --Patch
> name | used_bytes | free_bytes | total_bytes
> ---+++-
> RelCacheMemoryContext |4706464 |3682144 | 8388608
> CatCacheMemoryContext |3489384 | 770712 |
>
> Most catcache and relcache entries (other than index info etc.) currently
> go straight into CacheMemoryContext. And I believe these two caches can be
> the ones with the largest contribution to the memory usage of
> CacheMemoryContext most of the time. For example, in cases where we have
> lot
22 matches
Mail list logo
