On Wed, 6 Nov 2024 at 12:09, Tom Lane wrote:
> Of course, I might be overestimating the performance benefit we'd get.
> But I'm tempted to give it a try.
I'm glad. I'm curious to see if you're right about the projection
overhead of the flags. If you're right, it seems like a not too
difficult opt
David Rowley writes:
> On Tue, 5 Nov 2024 at 04:18, Tom Lane 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" ch
On Tue, 5 Nov 2024 at 04:18, Tom Lane 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 n
David Rowley writes:
> On Mon, 4 Nov 2024 at 22:52, ma lz 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
On Mon, 4 Nov 2024 at 22:52, ma lz wrote:
>
> some sql like ' select a from t1 intersect select a from t1 '
>
> if t1 has large number rows but has few distinct rows
>
> select distinct a from t1 intersect select distinct a from t1;— this is
> faster than origin sql
>
> can postgres do this o
