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
