Hi,
> > WHY SHALL IT MATERIALIZE A CONSTANT RESULT IN A LOOP OF 12 TIMES ??
> > [it would be enough to materialize only once,
>
> Which in fact is exactly what the materialize node is for. The reported
> costs are pretty bogus, but AFAICT the plan is the right thing.
Thanx for the
Hi all,
We've got the following 3 tables and 2 simple queries. The only difference
lies in the join condition: the first uses OR, the second uses AND.
I expected some difference in the performace according to the
difference in the evaluation of the logical form, but not
3 magnitudes !!!
So the
Hi All,
My question for this week:
How far is the above subject from beeing implemented?
(I've run through the archives, and found some quite old mails in
this topic. They mentioned automatically generated temp tables as possibe
solutions... Is this the plan even today?)
Attila
Ps.:
Two weeks
Hi,
> If that's what you write, yes. You can parenthesize the JOIN clauses
> any way you like, though, and the 7.1 planner will follow that structure.
Thanks for the exhaustive answer.
Can I test this feature in the current snapshot?
Attila
Hi,
> 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 ...
Do you mean a "linear binary tree" li
Hi,
> 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.
Changing this option in a psql session with 'set' has really helped
Thanks.
Hi all,
We are building a sophisticated and flexible database structure and thus,
we have quite complicated and longish queries containing lots of joins.
Using only a few test records in our structure we have performed some
measures, and it is hard to interpret the results.
Until we join no mor
