RE: Copy data to DSA area

Hi, thank you for the previous two emails.

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>What do you think about the following? Even though I know you want to start with
>much simpler kinds of cache, I'm looking ahead to the lofty end-goal of having a shared
>plan cache. No doubt, that involves solving many other problems that don't belong in
>this thread, but please indulge me:

My initial motivation came from shared catcache and relcache but I also think shared plan
cache is one of the big topics and I'd be very excited if it's come true. Sometimes making
plan at each backend becomes enormous overhead for speed.

>On Wed, Jul 10, 2019 at 6:03 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>> Hmm. I wonder if we should just make ShmContextFree() do nothing! And
>> make ShmContextAlloc() allocate (say) 8KB chunks (or larger if needed
>> for larger allocation) and then hand out small pieces from the
>> 'current' chunk as needed. Then the only way to free memory is to
>> destroy contexts, but for the use case being discussed, that might
>> actually be OK. I suppose you'd want to call this implementation
>> something different, like ShmRegionContext, ShmZoneContext or
>> ShmArenaContext[1].
>
><after sleeping on this>
>
>I guess what I said above is only really appropriate for complex things like plans that
>have their own contexts so that we can delete them easily "in bulk". I guess it's not
>true for caches of simpler objects like catcache, that don't want a context for each
>cached thing and want to free objects "retail" (one by one). So I guess you might
>want something more like your current patch for (say) SharedCatCache, and
>something like the above-quoted idea for (say) SharedPlanCache or SharedRelCache.

Here's what I get:
- Temporary/Permanent concept can be implemented by following current cached plan
schema of reparanting and also adding general API MemoryContextClone.

- There are at least two strategies (implementation ways) of allocation. One is
ShmZoneContext; region-based allocation, which drops chunks in bulk. This type is
useful for cache made of complex objects graph like plan cache. This case clean up
list (list of pointers to dsa_allocated objects) needs to be located in shared memory.
That's because this list is used not only in error case but in case of DropCachedPlan.

- The other is not region based, but allocate or free objects "retail". I would call it
ShmSimpleContext case. This would be suitable for, say, catalog cache.

The type of ShmSimpleContext is OK to have clean up list in local memory, right?
Unlike ShmZoneContext, this list is only used on error and cache entry can be
freed by just traversing simple object graph as discussed before.

Regarding the tracing list for cleanup, I'd change the design based on either
ShmSimpleContext or ShmZoneContext assuming the clean-up list would be
pointed by the context object in both type.

In type of ShmSimpleContext, the list is deleted after the context is reparent
to long lived one. The context for building, say, catcache entry is
located in shared memory but its tracking list is in local memory.
So it seems wired to that the shared object points to local object. But there
seems no problem because other process cannot touch the context until
its reparent.

In case of ShmZoneContext, it would be ok to still keep the list after its reparent.
That's because both this intermediate context and the list is supposed be
located in shared memory and used.

Regarding Intermediate level context, I was wondering if we need it in
ShmSimpleContext case. Every time we build the catcache entry, we make
MemoryContext object in shared memory and this becomes some memory
Overhead. But right now context object per catcache entry seems simple
architecture and moreover easier to operate on error case.

>For an implementation that supports retail free, perhaps you could store the address of
>the clean-up list element in some extra bytes before the returned pointer, so you don't
>have to find it by linear search. Next, I suppose you don't want to leave holes in the
>middle of the array, so perhaps instead of writing NULL there, you could transfer the
>last item in the array to this location (with associated concurrency problems).

Sure, I'll fix it.

>Since I don't think anyone ever said it explicitly, the above discussion is all about how
>we get to this situation, while making sure that we're mostly solving problems that
>occur in both multi-process and multi-threaded designs:
>
>shared_metadata_cache = '100MB'
>shared_plan_cache = '100MB'

Yes, we are talking about this. Thank you for the clarification.

Regards,
Takeshi Ideriha