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

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 23:01:44
Message-ID: 25460.1330556504@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 29, 2012 at 2:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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?

Well, yes, we know that much.

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

We don't know that --- I will agree it's likely, but that doesn't make
it so certain that we can assume it without checking.  A join condition
won't necessarily eliminate any rows.

(... thinks about that for awhile ...)  One thing we could possibly do
is have indxpath.c arbitrarily reject parameterizations that don't
produce a smaller estimated number of rows than an unparameterized scan.
Admittedly, this still doesn't *prove* the assumption for join
relations, but maybe it brings the odds to where it's okay for add_path
to make such an assumption.

(... thinks some more ...)  No, that doesn't get us there, because that
doesn't establish that a more-parameterized path produces fewer rows
than some path that requires less parameterization, yet not none at
all.  You really want add_path carrying out those comparisons.  In your
previous example, it's entirely possible that path D is dominated by B
or C because of poor choices of join quals.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2012-02-29 23:02:29
Subject: Re: pg_upgrade --logfile option documentation
Previous:From: Tom LaneDate: 2012-02-29 22:52:34
Subject: Re: 16-bit page checksums for 9.2

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