From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Parameterized-path cost comparisons need some work |
Date: | 2012-02-29 19:08:43 |
Message-ID: | 4952.1330542523@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2012-02-29 19:09:02 | Re: 16-bit page checksums for 9.2 |
Previous Message | Robert Haas | 2012-02-29 19:02:42 | Re: Parameterized-path cost comparisons need some work |