Skip site navigation (1) Skip section navigation (2)

Re: Parameterized-path cost comparisons need some work

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parameterized-path cost comparisons need some work
Date: 2012-02-29 22:40:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
>> 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).

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.

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-02-29 22:43:56
Subject: Re: Collect frequency statistics for arrays
Previous:From: Nathan BoleyDate: 2012-02-29 22:36:41
Subject: Re: Collect frequency statistics for arrays

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group