8000 Tracking: improve TPC-H performance · Issue #15036 · risingwavelabs/risingwave · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Tracking: improve TPC-H performance #15036

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
5 of 9 tasks
lmatz opened this issue Feb 6, 2024 · 2 comments
Open
5 of 9 tasks

Tracking: improve TPC-H performance #15036

lmatz opened this issue Feb 6, 2024 · 2 comments
Labels
no-issue-activity tracking Tracking issue. type/perf Type: Performance.

Comments

@lmatz
Copy link
Contributor
lmatz commented Feb 6, 2024 •
edited
Loading

See performance numbers at https://www.notion.so/risingwave-labs/TPCH-Performance-Numbers-Table-e098ef82884546949333409f0513ada7?pvs=4#8de0bf4bda51444c8381f3b0c10ddfe1

Improvements needed:
@lmatz lmatz added tracking Tracking issue. type/perf Type: Performance. labels Feb 6, 2024
@github-actions github-actions bot added this to the release-1.7 milestone Feb 6, 2024
@TennyZhuang TennyZhuang pinned this issue Feb 19, 2024
@lmatz
Copy link
Contributor Author
lmatz commented Feb 22, 2024 •
edited
Loading

2024-02-22

A temporary summary:

  1. q1 and q6 requires perf: throughput of stateless query with no computation drops 20% over time #14815
  2. q17's plan is still suboptimal
  3. q4's bottleneck is in LeftSemiJoin
  4. q20's bottleneck is also likely to be LeftSemiJoin as it has 2 LeftSemiJoin out of total 4 joins

2024-02-26

after some investigation:

q4's bottleneck is in LeftSemiJoin

Changing the barrier of both systems to 10s and using the latest image, the performance is about the same.

q20's bottleneck is also likely to be LeftSemiJoin as it has 2 LeftSemiJoin out of total 4 joins

The bottleneck is in the subquery, see #14797 for details

1 and 2 remains

2024-02-28

q20 reveals a potential problem in cache eviction strategy: #15305

2024-02-29

q4 also has a very similar observation caused by the cache eviction strategy: #14811 (comment)
Q4's LocalStoreIter::{Closure} takes an substantial amount of CPU time. See threads in the issue of Q4.

@xzhseh xzhseh unpinned this issue Feb 23, 2024
@xzhseh xzhseh pinned this issue Feb 23, 2024
@lmatz lmatz removed this from the release-1.7 milestone Mar 6, 2024
@emile-00 emile-00 unpinned this issue May 13, 2024
@github-actions GitHub Actions
Copy link
Contributor
6726

This issue has been open for 60 days with no activity. Could you please update the status? Feel free to continue discussion or close as not planned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
no-issue-activity tracking Tracking issue. type/perf Type: Performance.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@lmatz
0