From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | ma lz <ma100(at)hotmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Why not do distinct before SetOp |
Date: | 2024-11-05 23:09:41 |
Message-ID: | 3119567.1730848181@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Tue, 5 Nov 2024 at 04:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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?
> I've no idea why it's not like that. The current design is quite
> strange and feels dated. It might be worth making that change as even
> if we gave joins better support for IS NOT DISTINCT FROM and made
> INTERSECT use INNER JOIN instead and EXCEPT use anti join, we'd still
> need nodeSetOp.c for INTERSECT ALL and EXCEPT ALL.
Yeah. We'd still need it, and besides which it seems like a fairly
small project, unlike the other thing which could take multiple
years to get to an acceptable state.
Of course, I might be overestimating the performance benefit we'd get.
But I'm tempted to give it a try.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2024-11-05 23:38:00 | Re: Why not do distinct before SetOp |
Previous Message | Matt Zagrabelny | 2024-11-05 22:47:17 | Re: adsrc |