On Fri, Sep 3, 2010 at 5:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> 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, > > Yeah, but the converse isn't true. I had considered the idea of keeping > parameterized paths in a separate list, but you'd still have to examine > the main list to look for unparameterized paths that might dominate them.
Definitely true, but if it avoids slowing down add_path() in the common case, it's worth it. -- 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
