@@ -65,6 +65,27 @@ QuestDB instances), call
65
65
The two supported transport modes, HTTP and TCP, handle errors very differently.
66
66
In a nutshell, HTTP is much better at error handling.
67
67
68
+ # Health Check
69
+
70
+ The QuestDB server has a "ping" endpoint you can access to see if it's alive,
71
+ and confirm the version of InfluxDB Line Protocol with which you are
72
+ interacting:
73
+
74
+ ``` shell
75
+ curl -I http://localhost:9000/ping
76
+ ```
77
+
78
+ Example of the expected response:
79
+
80
+ ``` shell
81
+ HTTP/1.1 204 OK
82
+ Server: questDB/1.0
83
+ Date: Fri, 2 Feb 2024 17:09:38 GMT
84
+ Transfer-Encoding: chunked
85
+ Content-Type: text/plain; charset=utf-8
86
+ X-Influxdb-Version: v2.7.4
87
+ ```
88
+
68
89
## TCP
69
90
70
91
TCP doesn't report errors at all to the sender; instead, the server quietly
@@ -232,6 +253,21 @@ However, TCP has a lower overhead than HTTP and it's worthwhile to try out as an
232
253
alternative in a scenario where you have a constantly high data rate and/or deal
233
254
with a high-latency network connection.
234
255
256
+ ### Timestamp Column Name
257
+
258
+ InfluxDB Line Protocol (ILP) does not give a name to the designated timestamp,
259
+ so if you let this client auto-create the table, it will have the default name.
260
+ To use a custom name, create the table using a DDL statement:
261
+
262
+ ``` sql
263
+ CREATE TABLE sensors (
264
+ my_ts timestamp ,
265
+ id symbol,
266
+ temperature double,
267
+ humidity double,
268
+ ) timestamp (my_ts);
269
+ ```
270
+
235
271
## Sequential Coupling in the Buffer API
236
272
237
273
The fluent API of [ ` Buffer ` ] has sequential coupling: there's a certain order in
0 commit comments