Hi, On 2023-02-16 16:49:07 -0500, Jonah H. Harris wrote: > I've been working on a federated database project that heavily relies on > foreign data wrappers. During benchmarking, we noticed high system CPU > usage in OLTP-related cases, which we traced back to multiple brk calls > resulting from block frees in AllocSetReset upon ExecutorEnd's > FreeExecutorState. This is because FDWs allocate their own derived > execution states and required data structures within this context, > exceeding the initial 8K allocation, that need to be cleaned-up.
What PG version? Do you have a way to reproduce this with core code, e.g. postgres_fdw/file_fdw? What is all that memory used for? Is it possible that the real issue are too many tiny allocations, due to some allocation growing slowly? > Increasing the default query context allocation from ALLOCSET_DEFAULT_SIZES > to a larger initial "appropriate size" solved the issue and almost doubled > the throughput. However, the "appropriate size" is workload and > implementation dependent, so making it configurable may be better than > increasing the defaults, which would negatively impact users (memory-wise) > who aren't encountering this scenario. > > I have a patch to make it configurable, but before submitting it, I wanted > to hear your thoughts and feedback on this and any other alternative ideas > you may have. This seems way too magic to expose to users. How would they ever know how to set it? And it will heavily on the specific queries, so a global config won't work well. If the issue is a specific FDW needing to make a lot of allocations, I can see adding an API to tell a memory context that it ought to be ready to allocate a certain amount of memory efficiently (e.g. by increasing the block size of the next allocation by more than 2x). Greetings, Andres Freund
