On Thu, Dec 6, 2012 at 12:05 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Thu, Dec 6, 2012 at 2:27 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
>> On Wed, Dec 5, 2012 at 9:43 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
>>> As far as I can see on the explain, the misestimation is 3x~4x not 200x.
>>
>> It is 3x (14085 vs 4588) for selectivity on one of the tables, "Index
>> Only Scan using idx_trade_id_book on trade".
>>
>> But for the join of both tables it is estimate 2120 vs actual 11.
>
> But the final result set isn't further worked on (except for the
> aggregate), which means it doesn't affect the cost by much.
Good point. Both the NL and hash join do about the same amount of
work probing for success whether the success is actually there or not.
So scratch what I said about the correlation being important, in this
case it is not.
The 3x error is enough to push it over the edge, but the fudge factor
is what gets it so close to that edge in the first place.
And I'm now pretty sure the fudge factor change would fix this. The
truly-fast NL plan is getting overcharged by the fudge-factor once per
each 14,085 of the loopings, while the truly-slow bitmap scan is
overcharged only once for the entire scan. So the change is by no
means neutralized between the two plans.
I don't know if my other theory that the bitmap scan is overflowing
work_mem (but not costed for doing so) is also contributing.
Cheers,
Jeff
