Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 29, 2012 at 1:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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).

			regards, tom lane

In response to

• Re: Parameterized-path cost comparisons need some work at 2012-02-29 19:02:42 from Robert Haas

Responses

• Re: Parameterized-path cost comparisons need some work at 2012-02-29 22:40:23 from Robert Haas

pgsql-hackers by date

Next:	From: Heikki Linnakangas	Date: 2012-02-29 19:09:02
	Subject: Re: 16-bit page checksums for 9.2
Previous:	From: Robert Haas	Date: 2012-02-29 19:02:42
	Subject: Re: Parameterized-path cost comparisons need some work