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

On Wed, Jun 24, 2026 at 12:52 AM Zsolt Parragi
<zsolt(dot)parragi(at)percona(dot)com> wrote:
> I spent some more time thinking about my previous comments, as shortly
> after sending them I realized that it isn't as simple as I originally
> thought. I agree that a complete solution requires semantic analysis
> and is unrealistic.
>
> I ended up with a prototype that might slightly improve how these
> scenarios are handled. I attached two small patches containing it.
> These should handle most incorrect result issues, on the other hand
> they might result in some missed pushdowns. However, unless I'm
> mistaken, common cases should still be pushed down correctly as
> before?

Thanks for the patches and for digging into these two loose ends. I
considered your idea, but I'm inclined not to apply it, for a few
reasons.

My main concern is that it can cause plan regressions. It treats any
wrapper over a non-image-faithful grouping column as unsafe, but it
cannot tell a wrapper that exposes the hidden distinction from one
that provably cannot split a group. This mean queries with "GROUP BY
on a numeric/float/record column" would get slower even if they do not
have the unsafe-pushdown issue.

There's also the planning cost. The equalimage probe does a
SearchSysCacheList1 plus get_opfamily_proc plus an actual proc call
for every operand of every comparison considered for pushdown. That
cost is paid even for integer or deterministic-text grouping columns,
in which case we'd be spending the overhead just to reconfirm the
common safe case.

Stepping back: these unsafe-pushdown issues have been in the tree for
many years with no field reports. The current patch aims to fix the
most common cases with the least overhead, and to stay conservative
where covering a rare case would mean a lot more planning work and the
risk of a performance regression.

The equalimage idea itself is a nice observation, and if we ever
decide the wrapped case is common enough to be worth addressing, it's
probably the right tool. For now, I'm inclined to leave the two loose
ends documented as known limitations.

- Richard