On 04/29/15 18:26, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
...
>> OK, let me explain the context a bit more. When working on the
>> multivariate statistics patch, I need to choose which stats to use for
>> estimating the clauses. I do that in clauselist_selectivity(), although
>> there might be other places where to do that.
>
> Hm, well, clauselist_selectivity and clause_selectivity already contain
> extensive special-casing for RestrictInfos, so I'm not sure that I see why
> you're having difficulty working within that structure for this change.
So let's I'm in the clause_selectivity(), and have AND or OR clause to
estimate. I need to get varnos/varattnos for the clause(s). What should
I do? I can't call pull_varnos() or pull_varattnos() because there might
be nested RestrictInfos, as demonstrated by the query I posted.
> But there are basic reasons why expression_tree_walker should not try
> to deal with RestrictInfos; the most obvious one being that it's not
> clear whether it should descend into both the basic and OR-clause
> subtrees. Also, if a node has expression_tree_walker support then it
> should logically have expression_tree_mutator support as well, but
> that's got multiple issues. RestrictInfos are not supposed to be
> copied once created; and the mutator couldn't detect whether their
> derived fields are still valid.
OK, I do understand that. So what about pull_varnos_walker and
pull_varattnos_walker - what about teaching them about RestrictInfos?
--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
