Re: Reducing relcache memory usage: deduping index shapes

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Yilin Zhang <jiezhilove(at)126(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, David Geier <geidav(dot)pg(at)gmail(dot)com>
Subject: Re: Reducing relcache memory usage: deduping index shapes
Date: 2026-10-12 11:35:31
Message-ID: CAApHDvphxJOXTabFZAN9DJZHjd5SMMFFVhnsDt3y4sFFUcAGgw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 7 Oct 2026 at 11:01, Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
> 0004/0005:
> * Unchanged

I had a conversation with Andres about the Proxy context. He mentioned
that he gave it that name when he was experimenting with making it
work by putting the allocation in another memory context. I mentioned
using the "Direct" name, and he suggested "System", which I agreed was
a good name. We then agreed that we shouldn't call the .c file
system.c. systemcxt.c is likely ok.

Another review of 0004:

1. You could probably get rid of the allocSize variable in ProxyContextCreate()

2. struct ProxyBlock could use a few comments.

3. README:

* proxy.c (ProxyContext) is best suited for those use cases that require
long-lived allocations, with minimal allocation traffic, and generally
very few allocations; such as relcache's 'index info' contexts.

It might be worth mentioning how it works here as that'll help explain
to the reader why it's best suited for those cases. Maybe something
like:

* systemcxt.c (SystemContext) has no concept of grouping several allocations
* into blocks like many of the other allocators do. Each palloc() results in
* a malloc(), and each pfree() results in a free(), therefore, this isn't
* suitable for cases that require many allocations. The most suitable use
* cases are for contexts that require very few and long-lived allocations.
* The context header is also small, so this can be suitable when a large
* number of contexts are required.

Because we're getting so many context types now, I feel it's more
important than ever to have a central place that gives enough
information about each to allow someone to select the one that suits
their needs best.

4. The following existing text claims there are "three" other
allocators, but the patch makes that false since it introduces another
one:

aset.c (AllocSetContext) is our default general-purpose allocator. Three other
allocator types also exist which are special-purpose:

5. In ProxyRealloc(), can you clarify the following comment to mention
"When the size is being increased, randomize the new portion".

/* randomize the newly allocated memory */
#ifdef RANDOMIZE_ALLOCATED_MEMORY
if (block->sz < blksize)
randomize_mem(((char *) block) + block->sz, blksize - block->sz);
#endif

I just didn't find the current comment that informative since the
blocks are being swapped around, it takes a bit of study to see what's
meant to be going on there.

6. ProxyReset(). The following Assert() should be using
PROXY_CONTEXTSIZE as that's what ProxyContextCreate() set it to. It
just so happens to work because the size of the struct is already a
multiple of 8 bytes. Perhaps there are some systems where it won't
work.

Assert(ctx->header.mem_allocated == sizeof(ProxyContext));

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vaibhav Dalvi 2026-10-12 12:01:39 Re: [PATCH] Add support for INSERT ... SET syntax
Previous Message kedar anavardekar 2026-10-12 11:10:20 Re: Fix WITHOUT OVERLAPS multirange with location replication