Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Sep 2, 2010 at 5:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
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
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-09-03 18:16:01|
|Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) |
|Previous:||From: Heikki Linnakangas||Date: 2010-09-03 17:59:17|
|Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay,
Kevin! Thanks, reviewers!)|