On Wed, Feb 29, 2012 at 2:08 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Feb 29, 2012 at 1:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Indeed, and the code already knows that. However, in this example, path >>> A is capable of dominating the other three (being strictly less >>> parameterized than them), and B and C are each capable of dominating D. >>> The problem is just that I'd neglected to consider that rowcount now >>> also becomes a figure of merit. > >> In theory, yes, but in practice, won't it nearly always be the case >> that a less parameterized path generates more rows, and a more >> parameterized path generates less rows, so that neither dominates the >> other? > > I think you're just assuming that without any solid evidence. My point > is precisely that if the more-parameterized path *fails* to generate > fewer rows, we want add_path to notice that and throw it out (or at > least be able to throw it out, if there's not another reason to keep it).
Well, my "evidence" is that a parameterized path should pretty much always include a paramaterized path somewhere in there - otherwise, what is parameterization doing for us? And that's going to reduce the row count. I may be missing something, but I'm confused as to why this isn't nearly tautological. -- 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
