On Fri, Sep 3, 2010 at 5:53 PM, Tom Lane <[email protected]> wrote: > Robert Haas <[email protected]> writes: >> On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
