Re: Smoothing the subtrans performance catastrophe
От | Robert Haas |
---|---|
Тема | Re: Smoothing the subtrans performance catastrophe |
Дата | |
Msg-id | CA+TgmoYfkmS7aR2ZJv3WeV+hrj91w4b=3REDo4_zGQBBeuhxJQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Smoothing the subtrans performance catastrophe (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Wed, Aug 3, 2022 at 4:14 PM Andres Freund <andres@anarazel.de> wrote: > I don't think this scenario would fundamentally change - we already keep the > set of subxids in backend local memory (e.g. either a dedicated > TransactionStateData or an element in ->childXids) and in the locking table > (via XactLockTableInsert()). Sure.... > The problematic part isn't keeping "actually" running subxids in memory, but > keeping subxids that might be "considered running" in memory (i.e. subxids > that are considered running by an old snapshot in another backend). > > A hashtable just containing child->parent mapping for subxids doesn't actually > need that much memory. It'd be approximately (2 * 4 bytes) * subxids * > (2-fillfactor) or such? So maybe ~10MB for 1 milllion subxids? Allocating > that on-demand doesn't strike me as prohibitive. I mean the worst case is ~2 bn, no? -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: