Re: About method of PostgreSQL's Optimizer - Mailing list pgsql-hackers

From Jonah H. Harris
Subject Re: About method of PostgreSQL's Optimizer
Date
Msg-id 36e6829205091421394fbb062a@mail.gmail.com
Whole thread Raw
In response to Re: About method of PostgreSQL's Optimizer  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: About method of PostgreSQL's Optimizer
List pgsql-hackers
Tom,

I agree.  There have been several occasions where GEQO has performed poorly for me.  I'll search the archives for the past discussions.

sorry for sending this to you twice Tom... forgot to hit reply all :(

On 9/14/05, Tom Lane <tgl@sss.pgh.pa.us > wrote:
"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



--
Respectfully,

Jonah H. Harris, Database Internals Architect
EnterpriseDB Corporation
http://www.enterprisedb.com/

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Per-table freeze limit proposal
Next
From: "Jonah H. Harris"
Date:
Subject: Re: About method of PostgreSQL's Optimizer