From: | Yuya Watari <watari(dot)yuya(at)gmail(dot)com> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Performance Evaluation of Result Cache by using TPC-DS |
Date: | 2021-04-20 04:43:28 |
Message-ID: | CAJ2pMkYEMu8Qg1z_JkDM7k3KDVrB_5WDXf8R54OA-Uf-VHk_bw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello David,
Thank you for your reply.
> Thanks for running that again. I see from the EXPLAIN ANALYZE output
> that the planner did cost the Result Cache plan slightly more
> expensive than the Hash Join plan. It's likely that add_path() did
> not consider the Hash Join plan to be worth keeping because it was not
> more than 1% better than the Result Cache plan. STD_FUZZ_FACTOR is set
> so new paths need to be at least 1% better than existing paths for
> them to be kept. That's pretty unfortunate and that alone does not
> mean the costs are incorrect. It would be good to know if that's the
> case for the other queries too.
Thanks for your analysis. I understood why HashJoin was not selected
in this query plan.
> To test that, I've set up TPC-DS locally, however, it would be good if
> you could send me the list of indexes that you've created. I see the
> tool from the transaction processing council for TPC-DS only comes
> with the list of tables.
>
> Can you share the output of:
I listed all indexes on my machine by executing your query. I attached
the result to this e-mail. I hope it will help you.
Best regards,
Yuya Watari
Attachment | Content-Type | Size |
---|---|---|
all-indexes.txt | text/plain | 8.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-04-20 05:09:18 | Re: Table refer leak in logical replication |
Previous Message | Thomas Munro | 2021-04-20 04:43:07 | select 'x' ~ repeat('x*y*z*', 1000); |