Is GEQO behaving for everyone? Since line 160 of geqo_eval.c has
been commented out, GEQO has been behaving very strangely for me.
If I remove the #ifdef 0 and let it call compute_rel_size(), it
seems to work. Does the geqo need this?
If I leave that line out, it tries to put sorts in the middle of
plans and the join sequences make no sense. Using my test data,
the standard optimizer returns in about 9 seconds while geqo will
keep going seemingly forever and creating a temp file in the
data/base/dir. I've killed it after more than a minute before it
uses up all of my space.
If I uncomment that call to compute_rel_size() it returns in about
9 seconds too!
Vadim, Martin, are you sure that line is not somehow necessary to
geqo's performance?!?
I have the June 3rd and 8th tar files for testing this and only 2
files appear to have changed in that time according to the id
strings in the headers, geqo_erx.c and geqo_eval.c. The changes
to geqo_erx.c appear to be benign.
Is anyone else testing this?
I'm out for a few hours to go to class, but I'll come back in about
8:30pm Eastern time to check on this or provide any more info if
need be...
Darren darrenk@insightdist.com
BTW...
The difference between those two tars for the standard optimizer
is astounding...3rd version takes about 14 seconds for my test but
the 8th version takes only 8 seconds! And it did so using seq scans
instead of the indexes! Good work, Vadim...I'm truly impressed...
------------------------------
