Re: Parameterized-path cost comparisons need some work
От | Robert Haas |
---|---|
Тема | Re: Parameterized-path cost comparisons need some work |
Дата | |
Msg-id | CA+TgmoYgmvS7oKF5_r6ManXR1xd3JQW1L0Po=NEC0xzcKQXTyQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parameterized-path cost comparisons need some work (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Parameterized-path cost comparisons need some work
|
Список | pgsql-hackers |
On Wed, Feb 29, 2012 at 2:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Feb 29, 2012 at 1:40 PM, Tom Lane <tgl@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
В списке pgsql-hackers по дате отправления: