From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Meszaros Attila <tilla(at)draconis(dot)elte(dot)hu> |
Cc: | pgsql-sql(at)hub(dot)org |
Subject: | Re: Optimizing Multiply Joins ??? |
Date: | 2000-09-13 15:36:50 |
Message-ID: | 7866.968859410@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Meszaros Attila <tilla(at)draconis(dot)elte(dot)hu> writes:
> Until we join no more than 10 tables the response time is below 0.2 s.
> joining the 11th table comes with a dramatic change: response time
> usually grows up to 5-7 s,
That's interesting; apparently the regular optimizer is faster than the
GEQO optimizer for your style of query. Try increasing the GEQO
threshold (pg_option "geqo_rels") to more than 11.
> I have examined the output of explain in all 3 cases, and I have
> the feeling that the planner simply forgets the best solutions
> in 2nd and 3rd case.
The GEQO planner does not guarantee to find an optimal solution, it
just does a random search through a limited number of possible solutions
and uses the best one it happened across.
> But I think (hope) we could have a solution, because all of our
> complex joins are following foreign keys.
Actually, as the 7.1 code currently stands, a query that uses explicit
JOIN operators like yours does will always be implemented in exactly
the given join order, with no searching. I haven't quite decided if
that's a bug or a feature ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2000-09-13 15:46:03 | Re: PLSQL |
Previous Message | Jerome Raupach | 2000-09-13 14:40:44 | work on some tables in the same time. |