Horton

Re: Should HashSetOp go away

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-26T22:19:53Z
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 →

  1. Change "long" numGroups fields to be Cardinality (i.e., double).

  2. Improve planner's estimates of tuple hash table sizes.

  3. Use BumpContext contexts in TupleHashTables, and do some code cleanup.

  4. Convert SetOp to read its inputs as outerPlan and innerPlan.

  5. Use more efficient hashtable for execGrouping.c to speed up hash aggregation.

David Rowley <dgrowleyml@gmail.com> writes:
> If Hash Joins did support IS NOT DISTINCT FROM clauses, then at least
> the non-ALL cases could be done with Hash Semi Join and Hash Anti Join
> for INTERSECT and EXCEPT, respectively, followed by a HashAgg. I doubt
> it would be any faster for the general case, but at least it would
> allow those setop queries to run when the inputs don't fit in memory.
> It's not ideal though, as when the planner underestimates, Hashed
> Setops could still blow up.

Yeah.  As I hinted before, I think a better answer would be to teach
TupleHashTables to be able to spill to disk at need.  No idea how
much work that would be, but it would fix all users of that code
not just one of them.

			regards, tom lane