Thread

Re: Fix HAVING-to-WHERE pushdown with mismatched operator families

Thom Brown <thom@linux.com> — 2026-05-28T10:47:04Z

On Wed, 27 May 2026, 00:04 Richard Guo, <guofenglinux@gmail.com> wrote:

> 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.

Regards

Thom

>