Viewing profile — ryanbooz
ryanbooz
HN member- Joined
- Thu, Sep 24, 2020, 3:40 PM UTC
- HN karma
- 117
- Public activity
- 61 items
- HN profile
- View on Hacker News ↗
About ryanbooz
No profile information was provided.
Recent public activity
-
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.
- story
-
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…
-
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…
-
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. …
-
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)…
-
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…
-
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…
-
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).
-
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…
-
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…
-
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…
-
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 …
-
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…
-
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 …
-
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…
-
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 …
-
comment
Comment #28950182
(post author and Timescaler) What do you mean by "migrating old data"? Don't want to make assumptions before answering further.
-
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…
-
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…
-
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…
-
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.
-
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…
-
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 …
-
comment
Comment #28948132
Gotcha! My apologies for not seeing the thread nature. HN threads get me sometimes. :-)