| 99 | 1.3 |
| ... | ... | ... | ... | ... |
The "narrow" table is :
| time | device_Id | sensor_1 | sensor_2 |
| 1 | root.sg_1.device_1 | 100 | 2.5 |
| ... | ... | ... | ... |
| 1 | root.sg_1.device_2 | 99 | 1.3 |
| ... | ... | ... | ... |
On 9/7/2019 15:51，Rui, Lei wrote：
Hi,
I try to make this proposa
| 99 | 1.3 |
| ... | ... | ... | ... | ... |
On 9/7/2019 15:51，Rui, Lei wrote：
Hi,
I try to make this proposal more concrete from a semantic perspective.
Consider the sql "select * from root.sg_1". The following format is the "wide"
table:
The following format is the "narrow" tabl
Hi,
I try to make this proposal more concrete from a semantic perspective.
Consider the sql "select * from root.sg_1". The following format is the "wide"
table:
The following format is the "narrow" table:
The levels of data from low to high are:
- sensor data, or series data, e.g., from
Hi, I'm here to suggest another structure like this :)
(Structure 3):
.
├── LICENSE
├── NOTICE
├── changes.txt
│
├── bin
│ ├── client
│ │ ├── export-csv.bat
│ │ ├── export-csv.sh
│ │ ├── import-csv.bat
│ │ ├── import-csv.sh
│ │ ├── run-client.bat
│ │ ├──
Hi all,
I think it is worthwhile to spend some time discussing and hoping to reach a
consensus on what a good Git workflow should be.
Here is the thing. The branch 'feature_async_close_tsfile' that I have recently
been working on with others was merged into the master branch a few days ago.
This is the picture (bmp format) in 2.1.
-- 原始邮件 --
发件人: "suyue";
发送时间: 2019年6月24日(星期一) 晚上10:14
收件人: "dev";
主题: Re: Discussion: IoTDB Query on Value Columns
This is the picture in 2.1.
在 2019年6月24日，下午9:58，RUI, LEI <1010953...@q
1. Problem Description
Consider four data points (t,v) are written to IoTDB in the following order:
(1,1)
(2,2)
(3,3)
(1,100)
Then, given a query “select * from root where v<10”, the expected result is
(2,2)(3,3). This is because the later inserted data point (1,100) should cover
the
