On Wed, 27 May 2026, 00:04 Richard Guo, <[email protected]> wrote:
> On Tue, May 26, 2026 at 11:06 PM Thom Brown <[email protected]> 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. Regards Thom >
