Tom Lane wrote:
>>> Um, that is what the proposed patch does.
>> I was referring to the first two lines that the patch removes.
>> I guess I don't understand why they should go.
> What we'd have left after the proposed removal is
>
>if (new_path->rows < old_path->rows)
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> 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.
> Not impressed with this idea- the notion that our m
Simon Riggs writes:
> On Thu, Apr 19, 2012 at 11:39 PM, Tom Lane wrote:
>> 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.
> The fuzz factor is a better idea, IMHO. I
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> 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.
> Not impressed with this idea- the notion that our m
"Albe Laurenz" writes:
> Tom Lane wrote:
>> Um, that is what the proposed patch does.
> I was referring to the first two lines that the patch removes.
> I guess I don't understand why they should go.
What we'd have left after the proposed removal is
if (new_path->row
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> 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.
+1 on this approach
Tom Lane wrote:
>> What if you remove the exact cost comparison, but leave the part
where
>> old dominates new based on rows?
>
> Um, that is what the proposed patch does.
I was referring to the first two lines that the patch removes.
I guess I don't understand why they should go.
Anyway, I fail
"Albe Laurenz" writes:
> What if you remove the exact cost comparison, but leave the part where
> old dominates new based on rows?
Um, that is what the proposed patch does.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On 19 April 2012 23:39, Tom Lane 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:
>
> /*
>
Tom Lane WROTE.
> So after committing the latest round of parameterized-plan hacking,
> I was dismayed to see the buildfarm breaking out in pink, thanks to
> some of the members producing a different plan than expected for one
> test query. I eventually managed to reproduce that (on the fourth
> m
On Thu, Apr 19, 2012 at 11:39 PM, Tom Lane wrote:
> 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.
The fuzz factor is a better idea, IMHO. I would like to see that as
Jim Nasby writes:
> [ add some error ranges to cost estimates ]
> I believe that would fix this specific case because even though to plans
> might come out with a nearly identical cost it is unlikely that they would
> also have a nearly identical error range.
Actually, I think that *wouldn't*
On 4/19/12 5:39 PM, Tom Lane wrote:
Now, neither of these fixes is perfect: what they would do is remove
platform-specific instability from where the costs are basically equal
and add some more in the range where the costs differ by almost exactly
the fuzz factor. But the behavior near that poin
So after committing the latest round of parameterized-plan hacking,
I was dismayed to see the buildfarm breaking out in pink, thanks to
some of the members producing a different plan than expected for one
test query. I eventually managed to reproduce that (on the fourth
machine I tried locally), a
14 matches
Mail list logo
