Re: Use BumpContext contexts for TupleHashTables' tablecxt - Mailing list pgsql-hackers

From David Rowley
Subject Re: Use BumpContext contexts for TupleHashTables' tablecxt
Date
Msg-id CAApHDvp_k9axStkbZNmH62HFnJxBfevtjpnW7iE+57PFHT_Xog@mail.gmail.com
Whole thread Raw
In response to Use BumpContext contexts for TupleHashTables' tablecxt  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Use BumpContext contexts for TupleHashTables' tablecxt
Re: Use BumpContext contexts for TupleHashTables' tablecxt
List pgsql-hackers
On Mon, 27 Oct 2025 at 09:55, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: High CPU consumption in cascade replication with large number of walsenders
Next
From: Tomas Vondra
Date:
Subject: Re: PG18 GIN parallel index build crash - invalid memory alloc request size