On 18/7/2024 19:49, Matthias van de Meent wrote:
> On Wed, 17 Jul 2024 at 16:09, Andrei Lepikhov <lepihov@gmail.com> wrote:
>>
>> On 17/7/2024 16:33, Matthias van de Meent wrote:
>>> On Wed, 17 Jul 2024 at 05:29, Andrei Lepikhov <lepihov@gmail.com> wrote:
> Because the @<@ and @>@ operators are not registered as commutative,
> it couldn't apply the optimization in your patch, while the btree
> operator check does allow it to apply the optimization.
Ok, I got it.
And next issue: I think it would be better to save cycles than to free
some piece of memory, so why not to break the foreach cycle if you
already matched the opfamily?
Also, in the patch attached I added your smoothed test to the aggregates.sql
>
> Aside: Arguably, checking for commutator operators would not be
> incorrect when looking at it from "applied operators" point of view,
> but if that commutative operator isn't registered as opposite ordering
> of the same btree opclass, then we'd probably break some assumptions
> of some aggregate's sortop - it could be registered with another
> opclass, and that could cause us to select a different btree opclass
> (thus: ordering) than is indicated to be required by the aggregate;
> the thing we're trying to protect against hereYes, I also think if someone doesn't register < as a commutator to >,
it
may mean they do it intentionally: may be it is a bit different
sortings? - this subject is too far from my experience and I can agree
with your approach.
--
regards, Andrei Lepikhov