Skip to content
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.

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

Timescale performs poorly on last-loc #211

Open
slhuang opened this issue Aug 26, 2022 · 2 comments
Open

Timescale performs poorly on last-loc #211

slhuang opened this issue Aug 26, 2022 · 2 comments

Comments

@slhuang
Copy link

slhuang commented Aug 26, 2022

We generate and load IOT data into Timescale following exactly the readme.md (https://github.com/timescale/tsbs). However, we observe the query performance is very different from what reported in https://www.timescale.com/blog/how-to-benchmark-iot-time-series-workloads-in-a-production-environment/

For instance, the last-loc query takes around 14 minutes to finish on our server (with shared_buffer=128G, work_mem=4G, and maximum_worker_number=64). While the running time is around 1s in the blog. May we ask what else we need to tune in order to get that performance? Thanks!

FYI, we tried different physical layout configurations during data loading:

  1. --in-table-partition-tag=true --chunk-time=8h --field-index-count=1 --do-create-db=true --do-abort-on-exist=false
  2. --in-table-partition-tag=true --chunk-time=30m --field-index-count=1 --do-create-db=true --do-abort-on-exist=false
  3. --in-table-partition-tag=true --partitions=10 --chunk-time=30m --field-index-count=1 --do-create-db=true --do-abort-on-exist=false
    The first configuration is the same as what is in the readme.md. However, none of the above configurations leads to comparable performance as reported in the blog post. Would you please kindly provide some guidance to us? Thank you!
@dssysolyatin
Copy link

dssysolyatin commented Sep 12, 2022

I suspect that TimescaleDB benchmark code still create wrong index for --in-table-partition-tag=true
I described it before inside #182

@slhuang
Copy link
Author

slhuang commented Sep 12, 2022

I suspect that TimescaleDB benchmark code still create wrong index for --in-table-partition-tag=true I described it before inside #182

I see. Thanks for the information! Were you able to fix it and speed the query up? e.g., manually create the correct index (tag_id, time).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants