Donald Dong writes:
> Perhaps the cheapest-total-cost should not be the best/only choice
> for fitness?
Well, really the GEQO code should be thrown out and rewritten from
the ground up ... but that hasn't quite gotten done yet.
regards, tom lane
On May 23, 2019, at 10:43 AM, Tom Lane wrote:
> Donald Dong writes:
>> On May 23, 2019, at 9:02 AM, Tom Lane wrote:
>>> (2) the paths you show do not correspond to the finally selected
>>> plans --- they aren't even the same shape. (The Gathers are in
>>> different places, to start with.) I'm
Donald Dong writes:
> On May 23, 2019, at 9:02 AM, Tom Lane wrote:
>> (2) the paths you show do not correspond to the finally selected
>> plans --- they aren't even the same shape. (The Gathers are in
>> different places, to start with.) I'm not sure where you were
>> capturing the path data, b
On May 23, 2019, at 9:02 AM, Tom Lane wrote:
>
> Donald Dong writes:
>> On May 22, 2019, at 11:42 AM, Tom Lane wrote:
>>> You're still asking us to answer hypothetical questions unsupported
>>> by evidence. In what case does that really happen?
>
>> I attached the query plan and debug_print_r
Donald Dong writes:
> On May 22, 2019, at 11:42 AM, Tom Lane wrote:
>> You're still asking us to answer hypothetical questions unsupported
>> by evidence. In what case does that really happen?
> I attached the query plan and debug_print_rel output for GEQO and
> standard_join_search.
>
> "Finnerty" == Finnerty, Jim writes:
Finnerty> planstate-> total_cost cheapest_total_path
Finnerty> GEQO 54190.1354239.03
Finnerty> STD 54179.0254273.73
These differences aren't significant - the standard join search
Fwiw, I had an intern do some testing on the JOB last year, and he reported
that geqo sometimes produced plans of lower cost than the standard planner (we
were on PG10 at the time). I filed it under "unexplained things that we need
to investigate when we have time", but alas...
In any case, Do
On May 22, 2019, at 11:42 AM, Tom Lane wrote:
>
> Donald Dong writes:
>> I find the cost from cheapest_total_path->total_cost is different
>> from the cost from queryDesc->planstate->total_cost. What I saw was
>> that GEQO tends to form paths with lower
>> cheapest_total_path->total_cost (aka t
Donald Dong writes:
> I find the cost from cheapest_total_path->total_cost is different
> from the cost from queryDesc->planstate->total_cost. What I saw was
> that GEQO tends to form paths with lower
> cheapest_total_path->total_cost (aka the fitness of the children).
> However, standard_join_se
Hi,
Thank you very much for the explanation! I think the join order
benchmark I used [1] is somewhat representative, however, I probably
didn't use the most accurate cost estimation.
I find the cost from cheapest_total_path->total_cost is different
from the cost from queryDesc->planstate->total_
Donald Dong writes:
> I was expecting the plans generated by standard_join_search to have lower
> costs
> than the plans from GEQO. But after the results I have from a join order
> benchmark show that GEQO produces plans with lower costs most of the time!
> I wonder what is causing this observat
Hi,
I was expecting the plans generated by standard_join_search to have lower costs
than the plans from GEQO. But after the results I have from a join order
benchmark show that GEQO produces plans with lower costs most of the time!
I wonder what is causing this observation? From my understanding,
12 matches
Mail list logo
