From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, amdmi3(at)amdmi3(dot)ru, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Jakub Janeček <jakub(dot)janecek(at)comgate(dot)cz> |
Subject: | Re: BUG #15592: Memory overuse with subquery containing unnest() and set operations (11.x regression) |
Date: | 2019-02-09 17:19:08 |
Message-ID: | 24396.1549732748@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2019-02-09 23:10:18 | BUG #15625: 10.6.1 Can't Find hstore. |
Previous Message | Amit Langote | 2019-02-09 16:57:16 | Re: BUG #15623: Inconsistent use of default for updatable view |