David Rowley <dgrowleyml@xxxxxxxxx> writes: > On Mon, 4 Nov 2024 at 22:52, ma lz <ma100@xxxxxxxxxxx> wrote: >> select distinct a from t1 intersect select distinct a from t1; — this is faster than origin sql > No, the planner does not attempt that optimisation. INTERSECT really > isn't very well optimised. It's not really obvious to me why adding DISTINCT would make it faster. Seems like having two layers of plan nodes checking for duplicate rows ought to be a loss. Maybe we need to do some micro-optimization in or near LookupTupleHashEntry. A different idea that occurred to me while looking at this is: why have we got all this machinery to add and check a flag column, rather than arranging things so that the two input relations are "outer" and "inner" children of the SetOp? It's possible some of the performance difference reported here is due to having to pass more tuples through the SubqueryScan node (with its projection to add the flag) and Append node, but we could remove those steps entirely. > If we did want to improve this area, I think the first thing we'd want > to do is use standard join types rather than HashSetOp Intersect to > implement INTERSECT (without ALL). To do that efficiently, we'd need > to do a bit more work on the standard join types to have them > efficiently support IS NOT DISTINCT FROM clauses as the join keys. Maybe. It'd be a big project, but we do get complaints every so often about IS NOT DISTINCT FROM predicates not being efficient, so the benefits would be wider than just INTERSECT. regards, tom lane
