From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | sailesh(at)cs(dot)berkeley(dot)edu |
Cc: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: On query rewrite |
Date: | 2004-05-28 16:29:54 |
Message-ID: | 27704.1085761794@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu> writes:
> Thanks again. To confirm the actual cost comparison with plan
> enumeration is a dynamic programming algorithm, is it not ?
> Selinger-style with 2-way join paths enumerated, then 3-way using the
> best 2-way etc. ?
Correct. For details see make_one_rel_by_joins in path/allpaths.c
and make_rels_by_joins in path/joinrels.c (dunno why what's basically
a single algorithm is split across two files). There are some
heuristics involved concerning whether to consider clauseless joins,
so it's not totally trivial.
> BTW, do lots of people use the GEQO ?
Only people writing queries that join more than a dozen or so tables.
GEQO is another thing we've improved (I think) recently, but it's still
pretty weak IMHO. The algorithm is really designed to solve Traveling
Salesman problems, which bear only a crude resemblance to the behavior
of join problems. I'd like to see a more principled solution in there
someday.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-05-28 16:44:35 | Re: list rewrite committed |
Previous Message | Andreas Pflug | 2004-05-28 16:29:48 | Re: tablespaces and DB administration |