Re: Cost estimates for parameterized paths - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cost estimates for parameterized paths
Date
Msg-id 26520.1283537053@sss.pgh.pa.us
Whole thread Raw
In response to Re: Cost estimates for parameterized paths  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Cost estimates for parameterized paths  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Sep 2, 2010 at 5:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The best idea I can come up with at the moment is to compute "best case"
>> and "worst case" costs for a parameterized path,

> Interestingly, I previously proposed almost exactly this approach to
> handle a couple of other problems:

I thought it seemed familiar ;-)

> I'm not entirely sure whether we can use this approach for more than
> one kind of problem at a time; if we can't, it's probably not a good
> idea to do it at all.

I don't see why we couldn't do it in principle.  The issue of course
is how many paths survive, and can we tolerate that from a planner
performance standpoint?

On reflection I think that for parameterized paths the problem won't be
too bad, because (a) we'll ignore parameterized paths except when
considering a join to the right outer rel, so their presence in the
rel's pathlist won't cost much otherwise, and (b) we will only generate
them when there's a suitable joinclause, so the number of potential
paths will be limited.  I am not sure those statements can be made for
the other applications you suggested, though.

There's probably not much we can do at this point except code up the
idea and see how well it works.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Next
From: Tom Lane
Date:
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)