Hi,
2017-12-10 2:53 GMT+01:00 John R Pierce :
> I believe I would use boolean, not bit.
Agreed.
2017-12-10 10:01 GMT+01:00 Thomas Kellerer :
> Did you try to use a (single) hstore or jsonb column instead where the
> attribute name is the key?
Thought about that and I'm using hstore extensively
I actually made some tests on my own (using generate_series) and did
not find any disk space or performance issues yet.
I've also found this paper from 2012 about "Sensor Data Storage
Performance: SQL or NoSQL, Physical or Virtual" [2] which confirms my
observations.
Now, you have to know that t
On 12/9/2017 5:46 PM, Stefan Keller wrote:
Below I re-modeled it to a relational schema as you suggested and also
tried to utilize the INHERITS feature.
Does that look better?
I believe I would use boolean, not bit.
--
john r pierce, recycling bits in santa cruz
Hi
Thanks James and Steven!
I hoped somebody will advise me not to do this.
I was just bothered with NoSQL databases.
Even TimescaleDB made me wonder because it says it scales Postgres [1]
for IoT which implies that Postsgres does not scale...
2017-12-09 23:01 GMT+01:00 Steven Lembark :
> In gene
On Sat, 9 Dec 2017 20:22:02 +0100
Stefan Keller wrote:
> create table m1 (
> id bigint,
> created timestamp,
> b20 bit(20) default b'',
> farr20 float8[20]
> );
In general this is a bad idea *unless* you have benchmarked the
database and found that the am
My initial inclination is to always build the simplest to understand system
first. Space is cheap and pg is pretty efficient, engineering time is expensive
and debugging time doubly so with a side of anxiety when production goes down.
Also, it will allow more flexibility later on to describe you
Hi,
Given this kind of sensors (Internet-of-Things) log and monitoring scenario:
* There are 3 production machines monitored every few seconds for
forthcoming (~2) years.
* Machine m1 is emitting 20 boolean and 20 float4 captured in sensors
(m1s1..m1s40).
* Machine m2 has same attributes as m1 pl
