Re: Optimizing Multiply Joins ??? - Mailing list pgsql-sql

From Tom Lane
Subject Re: Optimizing Multiply Joins ???
Date
Msg-id 7866.968859410@sss.pgh.pa.us
Whole thread Raw
In response to Optimizing Multiply Joins ???  (Meszaros Attila <tilla@draconis.elte.hu>)
Responses Re: Optimizing Multiply Joins ???  (Meszaros Attila <tilla@draconis.elte.hu>)
Re: Optimizing Multiply Joins ???  (Meszaros Attila <tilla@draconis.elte.hu>)
List pgsql-sql
Meszaros Attila <tilla@draconis.elte.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


pgsql-sql by date:

Previous
From: Jerome Raupach
Date:
Subject: work on some tables in the same time.
Next
From: Ian Turner
Date:
Subject: Re: work on some tables in the same time.