| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Should HashSetOp go away |
| Date: | 2025-10-26 22:19:53 |
| Message-ID: | 2277801.1761517193@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
David Rowley <dgrowleyml(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2025-10-26 22:21:12 | Re: Use BumpContext contexts for TupleHashTables' tablecxt |
| Previous Message | David Rowley | 2025-10-26 22:16:41 | Re: Use BumpContext contexts for TupleHashTables' tablecxt |