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

From Robert Haas
Subject Re: Cost estimates for parameterized paths
Date
Msg-id AANLkTi=xxhWJ4u0Eqsb0+D04L4+M_MDvEvqv-=SpmG_a@mail.gmail.com
Whole thread Raw
In response to Re: Cost estimates for parameterized paths  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Cost estimates for parameterized paths  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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,

Hmm.  Maybe they should go into a separate path list, and perhaps we
could do the min/max calculations only with that pathlist (at least
for now), thus avoiding taking a generalized penalty to handle this
specific case.  IIUC, a parameterized path should never cause an
unparamaterized path to be thrown out, even if the unparameterized
path costs more than the worst-case cost for the parameterized path,
because the parameterized path constrains the possible join strategies
higher up, so what looked like a great idea at first blush might turn
out to suck when the chips are down.  Then, too, I'm not sure we can
even guarantee it will always be possible to form a valid plan around
a given parameterized path, which is another good reason not to
discard any unparameterized alternatives that may exist.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Next
From: David Blewett
Date:
Subject: Re: Streaming a base backup from master