Hello David,
Thank you for your reply.
> That's certainly one side of it. On the other side, it's pretty
> important to also note that in 4 of 23 queries the result cache plan
> executed faster but the planner costed it as more expensive.
>
> I'm not saying the costing is perfect, but what I am saying is, as you
> noted above, in 5 of 23 queries the result cache was cheaper and
> slower, and, as I just noted, in 4 of 23 queries, result cache was
> more expensive and faster. We know that costing is never going to be
> a perfect representation of what the execution time will be However,
> in these examples, we've just happened to get quite a good balance. If
> we add a penalty to result cache then it'll just subtract from one
> problem group and add to the other.
>
> Overall, in my tests execution was 1.15% faster with result cache
> enabled than it was without.
Thank you for your analysis. I agree with your opinion.
> I think it is more likely to be concerns like that one which would
> cause us to default enable_resultcache to off.
I am not sure whether this kind of degradation is common, but setting
default behavior to off is one of the realistic solutions.
Best regards,
Yuya Watari
