Skip site navigation (1) Skip section navigation (2)

Re: Planner creating ineffective plans on LEFT OUTERjoins

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Planner creating ineffective plans on LEFT OUTERjoins
Date: 2008-06-26 18:16:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, 2008-06-26 at 12:57 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> 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 specific hint, its a general goal setting.
> Right.  There are definitely places where we've made engineering
> judgements to not attempt a particular type of optimization because it'd
> be too expensive compared to the typical payoff.  Simon's idea has some
> merit for providing a framework to deal with that type of situation.
> However, just adding a GUC variable isn't going to make anything happen
> --- we'd need some concrete plans about what we'd do with it.

Well, I'm convinced the egg came first. 

So I figure to put the framework in place and then start reviewing
things to see if they can be categorised. Plus I want new optimizer
features to be considered in the light of the new framework. This also
allows us a way of handling optimizer performance bugs. We just
reclassify certain cases as being costs-more solutions, rather than
stripping the code out entirely.

 Simon Riggs 
 PostgreSQL Training, Services and Support

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-06-26 18:29:53
Subject: Re: get_relation_stats_hook()
Previous:From: Tom LaneDate: 2008-06-26 17:42:49
Subject: Re: Join Removal/ Vertical Partitioning

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group