Live data from Hacker News

Viewing profile — ryanbooz

ryanbooz

HN member
Joined
Thu, Sep 24, 2020, 3:40 PM UTC
HN karma
117
Public activity
61 items

About ryanbooz

No profile information was provided.

Recent public activity

  1. comment
    Comment #38558352

    The team at Tembo keeps working quickly to enable many different use cases with Postgres and extensions. Pretty fun example of how capable Postgres is for various tasks.

  2. story
  3. comment
    Comment #31827932

    Totally agree. Time is a primary component, but it might not always be the primary query parameter... at least once the data is aggregated. In the example you gave, I'd assume that…

  4. comment
    Comment #31827700

    (NB - post author) Great definition! Having worked for years on both energy and IoT applications, the argument here is that your "monthly sales data" is likely being aggregated fro…

  5. comment
    Comment #31827654

    (NB - post author) In a sense, it is. Continuous aggregates only have to materialize the most recent bucket of time, not the entire materialized view as you have to in PostgreSQL. …

  6. comment
    Comment #31827594

    (NB - blog author/Timescale employee) One thing we're improving as we move forward in documentation and other areas is explaining why doing joins (and things like window functions)…

  7. comment
    Comment #31824292

    (blog author) Thanks for the feedback! Out of curiosity, if the data you're trying to analyze doesn't have time as one of the critical components, what kind of data is it? Always h…

  8. comment
    Comment #30290547

    Timescale DevRel here! Great observations around how popular and useful it is for systems to have some level of Postgres line compatibility! Thanks for doing the writeup! One thing…

  9. comment
    Comment #28988628

    Heh - somehow missed that I had already responded to this one, my apologies. (and no immediate way to edit after the fact).

  10. comment
    Comment #28986732

    Thanks for your excellent contribution to this discussion. As the post author I wholly agree with your approach: if a solution hits the sweet spot for you in the context of your re…

  11. comment
    Comment #28960576

    You are correct. The current multi-node deployment (if you need it for your workload) does have one "managing" access node. All ANs and DNs can be replicated and configured with to…

  12. comment
    Comment #28960311

    (post author) Thanks for the great, thoughtful feedback. We (Timescale) couldn't agree more that there is a lot to love about ClickHouse, especially where it truly excels. Informat…

  13. comment
    Comment #28950645

    Looks like you edited this with some more detail, so I'll answer higher. Compression in TimescaleDB used to mean all compressed data was immutable and the table schema couldn't be …

  14. comment
    Comment #28950572

    In it's current form/state, ClickHouse is not optimized for typical JOIN-type queries, a point we make in the post. You would have to re-write your statement to get better performa…

  15. comment
    Comment #28950474

    1) you're absolutely right. 5k rows isn't "large". We also mentioned that we did hundreds of tests often going between 5k and 15k rows/batch. The overall ingest/query cycle didn't …

  16. comment
    Comment #28950365

    Sure, these tests were not using really large batch sizes because of the other benchmarks we were trying to replicate (but with more detail). Honestly, for this single instance set…

  17. comment
    Comment #28950277

    Great question. Yes, eventually it does, but (at least for now) it wasn't something we could reliably force as part of the query cycle and know everything was in it's "best" state …

  18. comment
    Comment #28950182

    (post author and Timescaler) What do you mean by "migrating old data"? Don't want to make assumptions before answering further.

  19. comment
    Comment #28950148

    (post author) You do a great job summarizing some of the benefits of ClickHouse we mentioned in the post, including the vectorized engine! That said, I'm not sure I'd refer to Post…

  20. comment
    Comment #28949237

    Yep - it's all detailed in the post! The question is how it compares to TimescaleDB, which is an OLTP time-series database that has a lot of other possible use cases (and extensibi…

  21. comment
    Comment #28949167

    Two quick responses: - The code that TSBS uses was contributed by Altinity[1]. If there is a better setup, please feel free to submit a PR. As stated elsewhere, we did have a forme…

  22. comment
    Comment #28948943

    Sure. As we shared in the blog post it was tested (like other benchmarks) on dedicated EC2 instances using the freely available Community version.

  23. comment
    Comment #28948823

    Hello @PeterZaitsev! Actually Altinity is the one that contributed the bits to TSBS for benchmarking ClickHouse[1], so we are using the work that they contributed (and anyone is we…

  24. comment
    Comment #28948686

    (post author) Those are great, impressive numbers. We certainly don't claim to be all things to all people, but the benchmark was run using single instances mostly because that is …

  25. comment
    Comment #28948132

    Gotcha! My apologies for not seeing the thread nature. HN threads get me sometimes. :-)