Re: Cost estimates for parameterized paths

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: Cost estimates for parameterized paths
Date: 2010-09-03 20:25:17
Message-ID: AANLkTi=xxhWJ4u0Eqsb0+D04L4+M_MDvEvqv-=SpmG_a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 3, 2010 at 2:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Adams 2010-09-03 20:40:56 OT: OFF TOPIC: returning multiple result sets from a stored procedure
Previous Message Heikki Linnakangas 2010-09-03 20:20:46 Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)