I would set Seed per default. Even worse than a bad query path
is an unpredictable query path. I see no argument, that a random Seed
would buy us anything.
This kindof bugs me -- if you leave it stuck at a preset value, it makes it
possible to never delve into parts of solution space that
You can remove the randomness by setting the Seed
configuration value,
True, but that's not the default setup.
I would set Seed per default. Even worse than a bad query path
is an unpredictable query path. I see no argument, that a random Seed
would buy us anything.
Andreas
Ed Loehr [EMAIL PROTECTED] writes:
What is the status of the genetic algorithm query optimizer? Is this
supposed to work well on many-table joins, or has it fallen out of favor
or in disrepair?
It's supposed to work ;-). I'm not sure that the default parameters are
optimal, however. If you
Tom Lane wrote:
Ed Loehr [EMAIL PROTECTED] writes:
What is the status of the genetic algorithm query optimizer? Is this
supposed to work well on many-table joins, or has it fallen out of favor
or in disrepair?
It's supposed to work ;-). I'm not sure that the default parameters are
Thomas Lockhart wrote:
What is the status of the genetic algorithm query optimizer? Is this
supposed to work well on many-table joins, or has it fallen out of favor
or in disrepair? [I'm needing to optimize some large, many-table-join
queries and wondering time spent
Ed Loehr [EMAIL PROTECTED] writes:
is there a reason why GEQO is off by
default in the ODBC driver (postdrv.exe)?
There may once have been a good reason for that, but it sounds like a
mighty bad idea nowadays.
AFAICT ODBC's default setting has been that way for as long as ODBC has
been in our
Peter Eisentraut [EMAIL PROTECTED] writes:
I've seen a number of bug reports that would indicate to me the GEQO works
less than perfectly. I vividly recall how, while working on my own code,
mere additions of dummy clauses like '... AND 5=5' altered query results
in seemingly random ways.
Tom Lane wrote:
The choices made by GEQO are intentionally random, so I would expect
variation in tuple output order even for repetitions of the identical
query. If you got a semantically different result, that would indeed
be a bug. But it would most likely be a bug in the core planner,
