2011/5/25 Tom Lane <t...@sss.pgh.pa.us>: > Robert Haas <robertmh...@gmail.com> writes: >> That was my first thought, too, but then I wondered if I was getting >> cheap. > > Yeah, it's certainly possible that we're worrying too much. Usually > I only get concerned about added planner logic if it will impact the > planning time for simple queries. "Simple" tends to be in the eye of > the beholder, but something with a complicated aggregate subquery is > probably not simple by anyone's definition. > > In this case the sticky point is that there could be multiple possible > sets of clauses available to be pushed down, depending on what you > assume is the outer relation for the eventual upper-level nestloop. > So worst case, you could have not just one parameterized plan to > generate in addition to the regular kind, but 2^N of them ...
My intention is that if join qual matches subqury Agg's grouping keys then the Var can be pushed down, so I'm not worried about the exponential possibilities of paths growth. And I found the right place to hack, where set_subquery_pathlist() pushes down some baseristrictinfo. We don't have Var in the RestrictInfo now, but I guess we can put them in it somehow before reaching there. Even if I can do it, the effective case is only outer is only one tuple case. As I noted earlier this optimization will complete by executor's cooperation, which is something like gather-param-values-as-array before starting Agg scan. So I'm still thinking which of pulling up and parameterized scan is better. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
