X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 4C8C0D869A for ; Thu, 15 Sep 2005 01:40:03 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 54738-05 for ; Thu, 15 Sep 2005 04:39:56 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by svr1.postgresql.org (Postfix) with ESMTP id A8381D8625 for ; Thu, 15 Sep 2005 01:39:55 -0300 (ADT) Received: by rproxy.gmail.com with SMTP id 40so32121rnz for ; Wed, 14 Sep 2005 21:39:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Nfo6lZbZ+wtpBrpMPAQcFZXPDwCXOaqHAM1FBVsPw2z+SgpyDk4mX96G4ZYKxYPYtzrrXXKpJvIeZ2rA4JeHwAIp6xbXN8kWypu6hKZVOV46QcKXCClkwGVvV1FNWDjqhBokIdI/0PgIia5W4+bICqEri39gIeNn+pq0cYWNH2Y= Received: by 10.11.119.31 with SMTP id r31mr282cwc; Wed, 14 Sep 2005 21:39:55 -0700 (PDT) Received: by 10.11.119.38 with HTTP; Wed, 14 Sep 2005 21:39:55 -0700 (PDT) Message-ID: <36e6829205091421394fbb062a@mail.gmail.com> Date: Thu, 15 Sep 2005 00:39:55 -0400 From: "Jonah H. Harris" Reply-To: jonah.harris@gmail.com To: Tom Lane Subject: Re: About method of PostgreSQL's Optimizer Cc: pryscila.lista@gmail.com, pgsql-hackers@postgresql.org In-Reply-To: <6127.1126720486@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7343_20490035.1126759195608" References: <36e6829205091320085993ceba@mail.gmail.com> <36e6829205091409361035d32a@mail.gmail.com> <6127.1126720486@sss.pgh.pa.us> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.533 required=5 tests=[AWL=0.004, HTML_20_30=0.504, HTML_MESSAGE=0.001, RCVD_BY_IP=0.024] X-Spam-Level: X-Archive-Number: 200509/682 X-Sequence-Number: 73079 ------=_Part_7343_20490035.1126759195608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Tom, I agree. There have been several occasions where GEQO has performed poorly= =20 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 wrote: >=20 > "Jonah H. Harris" writes: > > As for using both in the same optimizer, I could only see an algorithm= =20 > such > > as a customized-A* being used to planning *some* large queries. The=20 > 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=20 > calculation. >=20 > 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. >=20 > 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. >=20 > So it seems interesting to me to think about replacing GEQO with a > rule-based optimizer for large join search spaces. >=20 > There are previous discussions about this in the archives, I believe. >=20 > regards, tom lane >=20 --=20 Respectfully, Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation http://www.enterprisedb.com/ ------=_Part_7343_20490035.1126759195608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 o= nly see an algorithm such
> as a customized-A* being used to planning= *some* large queries. The reason I
> say this is because the cost ca= lculation, which would still need to be
> breadth-first, could calculate and cache the cost of most nodes th= ereby
> allowing you to possibly perform transformations at the tail = of calculation.

We do already have two different plan search algorit= hms: the strict
bottom-up dynamic programming approach (System R style) and the GEQOoptimizer, which we switch to when there are too many joins needed to
a= llow exhaustive search.  The GEQO code still depends on the norma= l
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) plan= s,
and the particular variant that we are using is really designed to so= lve
traveling-salesman problems.  It's at best a poor fit to the = join
planning problem.

So it seems interesting to me to think abo= ut replacing GEQO with a
rule-based optimizer for large join search spac= es.

There are previous discussions about this in the archives, I believe.
           &nb= sp;            = regards, tom lane



--
Respectfull= y,

Jonah H. Harris, Database Internals Architect
EnterpriseDB Cor= poration
http://www.enterprised= b.com/
------=_Part_7343_20490035.1126759195608--