Hi, On 2023-10-19 18:06:10 -0400, Stephen Frost wrote: > Ignoring such would defeat much of the point of this effort- which is to > get to a position where we can say with some confidence that we're not > going to go over some limit that the user has set and therefore not > allow ourselves to end up getting OOM killed.
I think that is a good medium to long term goal. I do however think that we'd be better off merging the visibility of memory allocations soon-ish and implement the limiting later. There's a lot of hairy details to get right for the latter, and even just having visibility will be a huge improvement. I think even patch 1 is doing too much at once. I doubt the DSM stuff is quite right. I'm unconvinced it's a good idea to split the different types of memory contexts out. That just exposes too much implementation detail stuff without a good reason. I think the overhead even just the tracking implies right now is likely too high and needs to be optimized. It should be a single math operation, not tracking things in multiple fields. I don't think pg_sub_u64_overflow() should be in the path either, that suddenly adds conditional branches. You really ought to look at the difference in assembly for the hot functions. Greetings, Andres Freund
