On 19 April 2012 23:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The idea that I'm toying with is to try to make the choice a bit less
> platform-specific, by removing the exact cost test that add_path uses
> as its last-ditch comparison step, essentially this:
>
> /*
> * Same pathkeys and outer rels, and fuzzily
> * the same cost, so keep just one; to decide
> * which, first check rows and then do an
> * exact cost comparison.
> */
> if (new_path->rows < old_path->rows)
> remove_old = true; /* new dominates old */
> - else if (new_path->rows > old_path->rows)
> - accept_new = false; /* old dominates new */
> - else if (compare_path_costs(new_path, old_path,
> - TOTAL_COST) < 0)
> - remove_old = true; /* new dominates old */
> else
> accept_new = false; /* old equals or dominates new */
>
> This change would mean that, when two paths have the same pathkeys,
> parameterization, and rowcount, and fuzzily the same cost, that we
> arbitrarily keep the first-submitted one rather than looking at low
> order digits of the costs. Since the order in which different paths
> are generated is a property of our code and not platform-specific,
> this should eliminate platform dependencies in cases where two paths
> are essentially identical to the cost model.
>
I think that the fuzz factor here is large enough that people would
notice, and it would inevitably lead to questions like "why did it
choose this plan whose cost is 127 over this one whose cost is 126?".
> A variant idea would be to replace the exact cost comparison with a
> second round of fuzzy cost comparison, but with a much tighter fuzz
> factor, maybe 1e-6 instead of 0.01.
>
That seems like a better approach. Given the accuracy of floating
point numbers, you could comfortably reduce that down to 1e-12 or even
less, which would be less user-visible but still remove any
platform-specific instability.
Regards,
Dean