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 21:46:01
Message-ID: CAApHDvp_k9axStkbZNmH62HFnJxBfevtjpnW7iE+57PFHT_Xog@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 27 Oct 2025 at 09:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> [ starting a new thread to keep this separate from the estimation
> issue ]
>
> I looked at the callers of BuildTupleHashTable, and realized that
> (a) every one of them can use a BumpContext for the "tablecxt",
> and (b) Jeff Davis already noticed that for nodeAgg.c, in commit
> cc721c459. So we have precedent for the idea working. Here's
> a fleshed-out patch to fix the remaining callers.

Yeah, this should give a decent performance improvement for larger workloads.

I can't help wonder if we can improve the memory context parameter
names in BuildTupleHashTable(). Every time I see "tablecxt" I have to
remind myself that it's not for the bucket array, just the stuff we
have the buckets point to. Would "hashedtuplecxt" be better?

If we did that, then the context names could use some of the same
treatment, "RecursiveUnion hashed tuples" and "SetOp hashed tuples" or
something.

The field name for TupleHashTableData.tablecxt and the comment (/*
memory context containing table */) also leads me into thinking it's
for the bucket array.

Maybe I'm unique in having that problem...

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-10-26 21:52:47 Re: PG18 GIN parallel index build crash - invalid memory alloc request size
Previous Message Alexander Korotkov 2025-10-26 21:03:23 Re: High CPU consumption in cascade replication with large number of walsenders