Re: Use BumpContext contexts for TupleHashTables' tablecxt

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Use BumpContext contexts for TupleHashTables' tablecxt
Date: 2025-10-26 22:16:41
Message-ID: CAApHDvrvDiETQo=xbHj9fCW=wPwMAgyouEo0ZQ5Wra_ARgvC_A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 27 Oct 2025 at 11:11, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Related to this, while I was chasing Jeff's complaint I realized that
> the none-too-small simplehash table for this is getting made in the
> query's ExecutorState. That's pretty awful from the standpoint of
> being able to blame memory consumption on the hash node. I'm not
> sure though if we want to go so far as to make another context just
> for the simplehash table. We could keep it in that same "tablectx"
> at the price of destroying and rebuilding the simplehash table, not
> just resetting it, at each node rescan. But that's not ideal either.

I don't think you could do that and have your patch as SH_GROW() needs
to pfree the old bucket array after rehashing, which bump won't like.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-10-26 22:19:53 Re: Should HashSetOp go away
Previous Message David Rowley 2025-10-26 22:14:32 Re: Should HashSetOp go away