From: Andres Freund <andres@anarazel.de>
> We waste a lot of space due to all these small contexts. Even leaving
> aside the overhead of the context and its blocks - not insignificant -
> they are mostly between ~1/2 a ~1/4 empty.
>
>
> But what if we had a new type of memory context that did not itself
> manage memory underlying allocations, but instead did so via the parent?
> If such a context tracked all the live allocations in some form of list,
> it could then free them from the parent at reset time. In other words,
> it'd proxy all memory management via the parent, only adding a separate
> name, and tracking of all live chunks.
It sounds like that it will alleviate the memory bloat caused by SAVEPOINT and RELEASE, which leave
CurTransactionContextfor each subtransaction. The memory overuse got Linux down when our customer's batch application
ranmillions of SQL statements in a transaction with psqlODBC. psqlODBC uses savepoints by default to enable statement
rollback.
(I guess this issue of one memory context per subtransaction caused the crash of Amazon Aurora on the Prime Day last
year.)
Regards
Takayuki Tsunakawa