Re: BUG #15592: Memory overuse with subquery containing unnest() and set operations (11.x regression)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-bugs@lists.postgresql.org, amdmi3@amdmi3.ru, Andrew Gierth <andrew@tao11.riddles.org.uk>, Jakub Janeček <jakub.janecek@comgate.cz>
Date: 2019-02-09T17:19:08Z
Lists: pgsql-bugs
Andres Freund <andres@anarazel.de> writes: > On 2019-02-09 10:09:57 -0500, Tom Lane wrote: >> What is it you're actually hoping to do by removing this guarantee? > I think we probably can do better in master, but I don't see a good > solution that's not expensive in v11. The tuple hash table can be > created / destroyed at a prodigious rate before 317ffdfea / 356687bd825, > and I don't see a good way to get rid of needing an ExprContext created > therein. We could register a callback on the memory context to drop the > ExprContext, but unfortunately dropping ExprContexts retail isn't > particularly cheap as it has to go through a singly linked list > (something we ought to fix one day by using a doubly linked list, but > certainly not a minor release). Why not? I think converting that list into a dlist might be a perfectly reasonable thing to do. Certainly there are ABI considerations in the back branches, but we could probably dodge those adequately with the usual hack of putting the added field at the end. regards, tom lane
Commits
-
Plug leak in BuildTupleHashTable by creating ExprContext in correct context.
- 9cf37a527cf8 11.2 landed
- 5567d12ce030 12.0 landed
-
simplehash: Add support for resetting a hashtable's contents.
- 350b0a40375e 11.2 landed
- 3b632a58e798 12.0 landed