Re: review: More frame options in window functions
From:
Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To:
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc:
Robert Haas <robertmhaas(at)gmail(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject:
Re: review: More frame options in window functions
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I think there's the associativity property of operators that we might
>> want to have someday, in order for the planner to know some more about
>> joins on A = B then on B = C, or replace with < if you will.
>
> We already do know about that, at least in the case of =. The reason it
> doesn't do transitive < deductions is not lack of information but doubt
> that it's worth the cycles to try.
Ok. I just remember about some mails here about the problem of
reordering [LEFT] JOINS when we can, but I can't remember if it's really
tied to associativity or some other thing.
Searching the archives ain't helping me refresh those memories. So it
seems the case for an extended opclass infrastructure, or a new side
one, is between thin an non-existent yet?
Regards,
--
dim
