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
Hi hackers,
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
lo
23 matches
Mail list logo
