RobAtticus

21 ms·

91.
by RobAtticus 9y ago
The claim wasn't "CPUs in 2017 are not faster than CPUs in 2003" or even "CPUs in 2017 are not much faster than CPUs in 2003"; the claim was that they haven't followed Moore's law since 2003, so applying i
92.
by RobAtticus 9y ago
I think the point is does it really make the US "incredibly uncompetitive" -- the original claim -- or is it closer to what you said, "a negative factor"? I think the person you responded to would agree it's a negat
93.
by RobAtticus 9y ago
Responding to your comment here: WaPo headline for CFPB story: Fight over consumer watchdog agency goes on as two acting directors try to take command HuffPo headline: CIVIL WAR AT FINANCE WATCHDOG! One is clearly more hysterical than the o
94.
by RobAtticus 9y ago
The content wasn't in question, the headlines were. The assertion was HuffPo has more hysterical headlines than WaPo
95.
How to scale PostgreSQL 10 using table inheritance and declarative partitioning(blog.timescale.com)
5 points by RobAtticus 9y ago|0 comments
96.
by RobAtticus 9y ago
Hey, thanks for the shout out :) In terms of resource-hungry-ness, while we haven't done extensive benchmarking on memory & CPU against InfluxDB, we should compare fine on those resources. The one area we do fall behind is disk usa
97.
by RobAtticus 9y ago
This is only popular vote for the president though. Each state has equal representation in the Senate, which is half of the law making process. Big states cannot simply ram through legislation that is slanted against small states. And since
98.
by RobAtticus 9y ago
We used it on an Ubuntu machine on Azure. We didn't do any real tuning yet, it was just an initial test to ballpark the benefit.
99.
by RobAtticus 9y ago
Thanks, great questions! 1) We are currently exploring all options for clustering, though we are likely to try something on our own. No final decisions made yet though. 2) One of the next tutorials we'd like to do is how to setup using
100.
by RobAtticus 9y ago
We used a pretty basic approach for both: 12 columns - timestamp, hostname, 10 CPU metrics.
101.
by RobAtticus 9y ago
We are working on benchmarks comparing ourselves to other solutions so hopefully we'll have concrete numbers on those soon. (Incidentally, we did a blog post on us vs plain PostgreSQL today: https://blog.timescale.com/t
102.
TimescaleDB vs. Postgres for time-series: Higher inserts, faster deletes, queries(blog.timescale.com)
10 points by RobAtticus 9y ago|0 comments
103.
by RobAtticus 9y ago
Obviously I'm biased, but in our testing of TimescaleDB we've found it to do well with large amounts of data. We're still working on benchmarks that we hope to present in the coming weeks/months, but we've been able
104.
by RobAtticus 9y ago
This was work done by our intern over the past few days using TimescaleDB. Our team is around to answer any questions!
105.
What the heck is time-series data (and why do I need a time-series database)?(blog.timescale.com)
3 points by RobAtticus 9y ago|0 comments
106.
by RobAtticus 9y ago
He's saying that since the S&P is at a higher multiple, you'd expect returns to diminish since presumably its too high to keep growing quickly (and, potentially, turn into a bear/down market). So by performing at average,
107.
by RobAtticus 9y ago
Not sure it's come up too often, but it's something we can think about going forward.
108.
by RobAtticus 9y ago
I'm not entirely sure what you mean by event sourcing. Can you elaborate?
109.
by RobAtticus 9y ago
Its tough to know exactly, because I think schema transformation would be the most time-comsuming part and its hard to say exactly how that goes. But once that's settled, for migrating your data, probably the most straight-forward mann
110.
by RobAtticus 9y ago
I personally haven't used Prometheus much, so I'm not sure I can effectively answer (a). I don't see why this would be difficult in TimescaleDB though. If it's timestamped, it should work nicely with our hypertable abstr
111.
by RobAtticus 9y ago
Earlier discussion about our launch (covering some of the points here): https://news.ycombinator.com/item?id=14035416 Around if there are any questions.
112.
Thank You HN: 20,000 views, 1000 stars, and 6 insights from the TimescaleDB launch(blog.timescale.com)
14 points by RobAtticus 9y ago|0 comments
113.
by RobAtticus 10y ago
While you do need to create tables for your stats, you are able to ALTER TABLE just as you can for normal Postgres without problem. It may not be as pain-free as NoSQL in that regard, but building tooling for this or automating this is cert
114.
by RobAtticus 10y ago
Clustering will be in the open-source version.
115.
by RobAtticus 10y ago
Influx has a framework[1] we are looking at utilizing, while adding other queries that they do not support (e.g., more complex predicates, non-time-based ordering, JOINs). We hope this will give a more accurate set of benchmarks for time-se
116.
by RobAtticus 10y ago
All good points. And especially agree about your last paragraph -- another benefit I didn't highlight is anyone familiar with Postgres does not have to learn a new part of the stack.
117.
by RobAtticus 10y ago
Sorry, not sure I follow. Do you mean how many partitions are supported? We allow up to two dimensions of partitioning: we always partition by time, and we allow you to specify another key on which to partition. Allowing multiple keys to pa
118.
by RobAtticus 10y ago
Its definitely something we want to make sure we get right before releasing. We do think single node can work for a lot of use cases though, especially with our scalable insert/write rates and our time-series specific optimizations.
119.
by RobAtticus 10y ago
Currently we are using the default storage mechanism in Postgres, but have had discussions on alternatives and other ways to compress our storage footprint.
120.
by RobAtticus 10y ago
We do acknowledge that storage is not our strong suit, but we think the benefits of having SQL and being able to integrate easily with non-time-series data is a big win itself. Certainly if storage is an issue for you, TimescaleDB is probab

More ›