Re: Parameterized-path cost comparisons need some work

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

In response to

Responses

Browse pgsql-hackers by date

  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