Re: BUG #15592: Memory overuse with subquery containing unnest() and set operations (11.x regression)

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

In response to

Browse pgsql-bugs by date

  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