Re: Performance Evaluation of Result Cache by using TPC-DS - Mailing list pgsql-hackers

From Yuya Watari
Subject Re: Performance Evaluation of Result Cache by using TPC-DS
Date
Msg-id CAJ2pMkbX1GyqQBQa6ZAjbW46tuWo=Rx1Qw9+v4XxB+N2=+Ppqg@mail.gmail.com
Whole thread Raw
In response to Re: Performance Evaluation of Result Cache by using TPC-DS  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Replication slot stats misgivings
Next
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.