Re: "Constraint exclusion" is not general enough

From: Rod Taylor <pg(at)rbt(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Martin Lesser <ml-pgsql(at)bettercom(dot)de>
Subject: Re: "Constraint exclusion" is not general enough
Date: 2006-08-08 02:23:27
Message-ID: 1155003807.749.12.camel@home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2006-08-07 at 22:01 -0400, Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> > Tom Lane wrote:
> >> But you don't have any cost numbers until after you've done the plan.
>
> > Couldn't this work similar to geqo_effort? The planner could
> > try planning the query using only cheap algorithmns, and if
> > the cost exceeds a certain value, it'd restart, and use
> > more sophisticated methods.
>
> AFAICS this would be a net loss on average. Most of the time, the
> constraint exclusion code doesn't win, and so throwing away all your
> planning work to try it is going to be a loser most of the time.

If constraint exclusion does not make any changes, mark the plan as
invalid, then there is no need to replan.

1. Generate plan cheaply
2. If under $threshold, execute query. The cost of further planning
is significant compared to executing this potentially
non-optimal plan.
3. Run constraint exclusion. If it changes the clauses due to
constraint exclusion, mark the plan as invalid. I assume
constraint exclusion is relatively self contained.
4. Invalid plan is replanned. Still valid plan (no potential
improvements can be made) is executed.

--

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message ITAGAKI Takahiro 2006-08-08 03:16:53 Re: CSStorm occurred again by postgreSQL8.2
Previous Message Tom Lane 2006-08-08 02:01:15 Re: "Constraint exclusion" is not general enough