On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > On reflection I think that for parameterized paths the problem won't be > too bad, because (a) we'll ignore parameterized paths except when > considering a join to the right outer rel, so their presence in the > rel's pathlist won't cost much otherwise,
Hmm. Maybe they should go into a separate path list, and perhaps we could do the min/max calculations only with that pathlist (at least for now), thus avoiding taking a generalized penalty to handle this specific case. IIUC, a parameterized path should never cause an unparamaterized path to be thrown out, even if the unparameterized path costs more than the worst-case cost for the parameterized path, because the parameterized path constrains the possible join strategies higher up, so what looked like a great idea at first blush might turn out to suck when the chips are down. Then, too, I'm not sure we can even guarantee it will always be possible to form a valid plan around a given parameterized path, which is another good reason not to discard any unparameterized alternatives that may exist. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
