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
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
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|