Hi,
Related to my development (putting relcache and catcache onto shared memory)[1],
I have some questions about how to copy variables into shared memory, especially DSA area, and its implementation way.
Under the current architecture when initializing some data, we sometimes copy certain data using some specified functions
such as CreateTupleDescCopyConstr(), datumCopy(), pstrdup() and so on. These copy functions calls palloc() and allocates the
copied data into current memory context.
But on the shared memory, palloc() cannot be used. Now I'm trying to use DSA (and dshash) to handle data on the shared memory
so for example dsa_allocate() is needed instead of palloc(). I hit upon three ways to implementation.
A. Copy existing functions and write equivalent DSA version copy functions like CreateDSATupleDescCopyConstr(),
datumCopyDSA(), dsa_strdup()
In these functions the logic is same as current one but would be replaced palloc() with dsa_allocate().
But this way looks too straight forward and code becomes less readable and maintainable.
B. Using current functions and copy data on local memory context temporarily and copy it again to DSA area.
This method looks better compared to the plan A because we don't need to write clone functions with copy-paste.
But copying twice would degrade the performance.
C. Enhance the feature of palloc() and MemoryContext.
This is a rough idea but, for instance, make a new global flag to tell palloc() to use DSA area instead of normal MemoryContext.
MemoryContextSwitchToDSA(dsa_area *area) indicates following palloc() to allocate memory to DSA.
And MemoryContextSwitchBack(dsa_area) indicates to palloc is used as normal one.
MemoryContextSwitchToDSA(dsa_area);
palloc(size);
MemoryContextSwitchBack(dsa_area);
Plan C seems a handy way for DSA user because people can take advantage of existing functions.
What do you think about these ideas?
[1]
https://www.postgresql.org/message-id/4E72940DA2BF16479384A86D54D0988A567B9245%40G01JPEXMBKW04
Regards,
Takeshi Ideriha
