To: jonah.harris@gmail.com
Cc: pryscila.lista@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: About method of PostgreSQL's Optimizer 
In-reply-to: <36e6829205091409361035d32a@mail.gmail.com> 
References: <cf0868bd05091315503024742@mail.gmail.com>
	<cf0868bd05091317412310c490@mail.gmail.com>
	<36e6829205091320085993ceba@mail.gmail.com>
	<cf0868bd050914085233eae603@mail.gmail.com>
	<36e6829205091409361035d32a@mail.gmail.com>
Comments: In-reply-to "Jonah H. Harris" <jonah.harris@gmail.com>
	message dated "Wed, 14 Sep 2005 12:36:37 -0400"
Date: Wed, 14 Sep 2005 13:54:46 -0400
Message-ID: <6127.1126720486@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Jonah H. Harris" <jonah.harris@gmail.com> writes:
> As for using both in the same optimizer, I could only see an algorithm such 
> as a customized-A* being used to planning *some* large queries. The reason I 
> say this is because the cost calculation, which would still need to be 
> breadth-first, could calculate and cache the cost of most nodes thereby 
> allowing you to possibly perform transformations at the tail of calculation.

We do already have two different plan search algorithms: the strict
bottom-up dynamic programming approach (System R style) and the GEQO
optimizer, which we switch to when there are too many joins needed to
allow exhaustive search.  The GEQO code still depends on the normal
plan cost estimation code, but it doesn't consider every possible plan.

I've never been very happy with the GEQO code: the random component of
the algorithm means you get unpredictable (and sometimes awful) plans,
and the particular variant that we are using is really designed to solve
traveling-salesman problems.  It's at best a poor fit to the join
planning problem.

So it seems interesting to me to think about replacing GEQO with a
rule-based optimizer for large join search spaces.

There are previous discussions about this in the archives, I believe.

			regards, tom lane