Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-27 Thread Florian Pflug
Tom Lane wrote: Simon Riggs <[EMAIL PROTECTED]> writes: On Thu, 2008-06-26 at 12:36 -0400, Robert Haas wrote: It's my understanding that the philosophy of the PGDG in the past has been to avoid putting any kind of hints into the system, focusing rather an improving the planning of queries. I

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Tom Lane
Andres Freund <[EMAIL PROTECTED]> writes: >> The only way it could do that would be by interchanging the order of the >> left and inner joins, ie (ab left join bc) join cd; which would change >> the results. > My knowledge about the implementation side of relational databases is quite > limited,

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Andres Freund
Hi, On Thursday 26 June 2008 04:36:09 Tom Lane wrote: > Andres Freund <[EMAIL PROTECTED]> writes: > > SELECT * > > FROM > > ab LEFT OUTER JOIN ( > > bc JOIN cd > > ON bc.c = cd.d > > ) > > ON ab.b = bc.b > > > > WHERE > > ab.a = 2 > > > > As ab.a = 2

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Ron Mayer
Tom Lane wrote: Ron Mayer <[EMAIL PROTECTED]> writes: Couldn't the planner itself make a good guess if it should keep trying based on the estimated cost? if (the_best_plan_I_found_so_far_looks_like_itll_take_an_hour) keep_optimizing_for_a_few_minutes if (the_best_plan_I_found_so_far_looks_

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Tom Lane
Ron Mayer <[EMAIL PROTECTED]> writes: > Couldn't the planner itself make a good guess if it should > keep trying based on the estimated cost? > if (the_best_plan_I_found_so_far_looks_like_itll_take_an_hour) >keep_optimizing_for_a_few_minutes > if (the_best_plan_I_found_so_far_looks_like_itll_t

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Ron Mayer
Simon Riggs wrote: IMHO we should have a single parameter which indicates how much planning time we consider acceptable for this query. e.g. optimization_level = 2 (default), varies 1-3 Couldn't the planner itself make a good guess if it should keep trying based on the estimated cost? if (th

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Simon Riggs
On Thu, 2008-06-26 at 12:57 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > On Thu, 2008-06-26 at 12:36 -0400, Robert Haas wrote: > >> It's my understanding that the philosophy of the PGDG in the past has > >> been to avoid putting any kind of hints into the system, focusing >

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Tom Lane
Simon Riggs <[EMAIL PROTECTED]> writes: > On Thu, 2008-06-26 at 12:36 -0400, Robert Haas wrote: >> It's my understanding that the philosophy of the PGDG in the past has >> been to avoid putting any kind of hints into the system, focusing >> rather an improving the planning of queries. > It's not a

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Simon Riggs
On Thu, 2008-06-26 at 12:36 -0400, Robert Haas wrote: > > IMHO we should have a single parameter which indicates how much planning > > time we consider acceptable for this query. e.g. > > > > optimization_level = 2 (default), varies 1-3 > > > > Most automatic optimisation systems allow this kind

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Robert Haas
> IMHO we should have a single parameter which indicates how much planning > time we consider acceptable for this query. e.g. > > optimization_level = 2 (default), varies 1-3 > > Most automatic optimisation systems allow this kind of setting, whether > it be a DBMS, or compilers (e.g. gcc). It's

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Chris Browne
[EMAIL PROTECTED] (Simon Riggs) writes: > On Wed, 2008-06-25 at 23:34 -0400, Robert Haas wrote: >> I can predict that Tom will say that the planning time it would take >> to avoid this problem isn't justified by the number of queries that it >> would improve. > >> That's possible, but it's unfort

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-26 Thread Simon Riggs
On Wed, 2008-06-25 at 23:34 -0400, Robert Haas wrote: > I can predict that Tom will say that the planning time it would take > to avoid this problem isn't justified by the number of queries that it > would improve. > That's possible, but it's unfortunate that there's no > way to fiddle with the

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-25 Thread Tom Lane
"Robert Haas" <[EMAIL PROTECTED]> writes: > I can predict that Tom will say that the planning time it would take > to avoid this problem isn't justified by the number of queries that it > would improve. Took the words right out of my mouth ;-) It would be *possible* to do this sort of thing, but

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-25 Thread Robert Haas
>> SELECT * FROM ab LEFT OUTER JOIN (bc JOIN cd ON bc.c = cd.d) ON ab.b = bc.b >> WHERE ab.a = 2 >> As ab.a = 2 occurs only once in ab one would expect that it just does an >> index scan on bc for ab.b = bc.b. > > The only way it could do that would be by interchanging the order of the > le

Re: [HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-25 Thread Tom Lane
Andres Freund <[EMAIL PROTECTED]> writes: > SELECT * > FROM > ab LEFT OUTER JOIN ( > bc JOIN cd > ON bc.c = cd.d > ) > ON ab.b = bc.b > WHERE > ab.a = 2 > As ab.a = 2 occurs only once in ab one would expect that it just does an

[HACKERS] Planner creating ineffective plans on LEFT OUTER joins

2008-06-25 Thread Andres Freund
Hi, After pondering on the problem for quite some time and discussing it on IRC with RhodiumToad I thought the most sensible thing is to post the problem here (as RhodiumToad suggested as well). The original (although already quite reduced) problematic query and the related plan: http://anaraz