Re: Fix HAVING-to-WHERE pushdown with nondeterministic collations - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Fix HAVING-to-WHERE pushdown with nondeterministic collations
Date
Msg-id CAMbWs4-B1qNNf5oATbeqrUYwnTShz9=mdDh2=bcq1QREBYv0wg@mail.gmail.com
Whole thread
In response to Re: Fix HAVING-to-WHERE pushdown with nondeterministic collations  (wenhui qiu <qiuwenhuifx@gmail.com>)
List pgsql-hackers
On Wed, Apr 1, 2026 at 11:19 AM wenhui qiu <qiuwenhuifx@gmail.com> wrote:
> > + vars = pull_var_clause(node, PVC_RECURSE_PLACEHOLDERS);
> > +
> > + foreach_node(Var, var, vars)
> > + {
> > + if (var->varno == *group_rtindex &&
> > + OidIsValid(var->varcollid) &&
> > + var->varcollid != inputcollid &&
> > + !get_collation_isdeterministic(var->varcollid))
> > + {
> > + list_free(vars);
> > + return true;
> > + }
> > + }
> > +
> > + list_free(vars);

> This might be overthinking, but I wonder if calling pull_var_clause() at each walker step could introduce some
overheaddue to repeated subtree scans 

That's a good point, but I doubt that it'd be an issue in practice.
HAVING clauses are typically very small expressions.  Even in unusual
queries, the clause size is bounded by what a human writes, which is
negligible compared to the work the planner does elsewhere.

Maybe we can avoid this by calling pull_var_clause once at the top of
each clause and reusing that var list at every node.  But that can
introduce false positives.  The pre-pulled list contains all GROUP
Vars from the entire clause, but a given operator node only acts on
the vars in its own subtree.

- Richard



pgsql-hackers by date:

Previous
From: Imran Zaheer
Date:
Subject: Silence -Wmaybe-uninitialized warnings
Next
From: Ashutosh Sharma
Date:
Subject: Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication