On Wed, Feb 29, 2012 at 2:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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).
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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2012-02-29 22:43:56|
|Subject: Re: Collect frequency statistics for arrays |
|Previous:||From: Nathan Boley||Date: 2012-02-29 22:36:41|
|Subject: Re: Collect frequency statistics for arrays|