Martin S. Utesch wrote:
>
> Vadim wrote:
>
> > Martin, I see that geqo_eval.c:gimme_tree() also calls compute_rel_size()
> > while compute_joinrel_size() already called by
> > geqo_paths.c:geqo_rel_paths(). After commenting out compute_rel_size()
> > GEQO returns good plan too. But I didn't change CVS...
> > Your decision ?
>
> I trust your decision. Do it.
Ok.
> What about *compute_rel_width*?
All right here.
>
> Please also have a look at the following...
>
> 1.) In case of *standard PG optimizer* the following would be relevant:
> joinrels.c:init_join_rel->set_joinrel_size
> ^^^^^^^^^^^^^^^^(this seems to be a hack)
> This is the first time the size of a new created joinrel is touched.
> Is the code o.k.?
>
> 2.) In case of *GEQO* the following would be relevant:
> geqo_eval.c:init_join_rel->geqo_joinrel_size
> ^^^^^^^^^^^^^^^^^which is the same as
> set_joinrel_size, but it makes log2 of the output if the value
> rel->size becomes bigger than MAXINT. I encounterd such several
> times. It's a pity that t'rel size is defined as int, not float so
> that such hacks are neccessary :-(
I havn't time currently, but you're right - we need in some cleanups here.
Vadim
------------------------------
