Re: Should HashSetOp go away

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Jeff Janes <jeff.janes@gmail.com>

Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2025-10-31T19:22:27Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Change "long" numGroups fields to be Cardinality (i.e., double).
- 8f29467c57f4 19 (unreleased) landed
Improve planner's estimates of tuple hash table sizes.
- 1ea5bdb00bfb 19 (unreleased) landed
Use BumpContext contexts in TupleHashTables, and do some code cleanup.
- c106ef08071a 19 (unreleased) landed
Convert SetOp to read its inputs as outerPlan and innerPlan.
- 27627929528e 18.0 cited
Use more efficient hashtable for execGrouping.c to speed up hash aggregation.
- 5dfc198146b4 10.0 cited

Attachments

v2-0001-Improve-planner-s-estimates-of-tuple-hash-table-s.patch (text/x-diff) patch v2-0001
v2-0002-Change-long-numGroups-fields-to-be-Cardinality-i..patch (text/x-diff) patch v2-0002

I wrote:
> Here's a pair of patches to try to do better.  The first one
> is concerned with getting more realistic size estimates for
> TupleHashTables in the planner.  The second is some mop-up
> that's been pending for a long time in the same area, namely
> getting rid of "long int" field types in Plan nodes.

Meh ... cfbot found a compiler warning that I'd not seen locally.
v2 attached silences that, and I twiddled a couple of comments.

			regards, tom lane