On Wed, Apr 29, 2015 at 12:33 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > On 04/29/15 18:26, Tom Lane wrote: >> Tomas Vondra <tomas.von...@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?
Tom: This patch has become part 1 of many under the "multivariate statistics vNNN" family of threads, but I guess it would be helpful if you could opine on the reasonable-ness of this approach. I don't want to commit anything over your objections, but this kind of tailed off without a conclusion. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers