On Tue, May 26, 2026 at 11:06 PM Thom Brown <thom@linux.com> wrote: > Makes sense to me, but out of curiosity, while digging into these > opfamily mismatches, have you noticed if this same record_ops vs > record_image_ops inequality poses any risks to other optimisation > paths like window function pushdowns or partition pruning? And > apologies if that has already been discussed, but I couldn't find > mention of it.
Thanks for raising these points. For partition pruning, match_clause_to_partition_key() already checks both collation and opfamily compatibility, so I don't think it has similar issues. I'm not sure what is meant by "window function pushdowns", but your question prompted me to look around, and I did notice that pushing restriction clauses down into a subquery suffers from a similar problem, specifically, when the subquery has DISTINCT, DISTINCT ON, or a window PARTITION BY clause.
Yeah, sorry, that wording wasn't clear. I just meant pushing a qual down past a window function's PARTITION BY, which is the one case the planner allows. Looks like that's exactly the rank() case you turned up, so you've answered it better than I could have asked it. The v2 approach of treating the whole thing as one bug class looks like the right call to me.
