- [How do I include a single quote in a password?](#how-do-i-include-a-single-quote-in-a-password)
- [How can I identify my version of InfluxDB?](#how-can-i-identify-my-version-of-influxdb)
- [Where can I find InfluxDB logs?](#where-can-i-find-influxdb-logs)
- [What is the relationship between shard group durations and retention policies?](#what-is-the-relationship-between-shard-group-durations-and-retention-policies)
- [Why aren't data dropped after I've altered a retention policy?](#why-aren-t-data-dropped-after-i-ve-altered-a-retention-policy)
- [Why does InfluxDB fail to parse microsecond units in the configuration file?](#why-does-influxdb-fail-to-parse-microsecond-units-in-the-configuration-file)
- [Does InfluxDB have a file system size limit?](#does-influxdb-have-a-file-system-size-limit)
- [What determines the time intervals returned by `GROUP BY time()` queries?](#what-determines-the-time-intervals-returned-by-group-by-time-queries)
- [Why do my queries return no data or partial data?](#why-do-my-queries-return-no-data-or-partial-data)
- [Why don't my `GROUP BY time()` queries return timestamps that occur after `now()`?](#why-don-t-my-group-by-time-queries-return-timestamps-that-occur-after-now)
- [Can I perform mathematical operations against timestamps?](#can-i-perform-mathematical-operations-against-timestamps)
- [Can I identify write precision from returned timestamps?](#can-i-identify-write-precision-from-returned-timestamps)
- [When should I single quote and when should I double quote in queries?](#when-should-i-single-quote-and-when-should-i-double-quote-in-queries)
- [Why am I missing data after creating a new `DEFAULT` retention policy?](#why-am-i-missing-data-after-creating-a-new-default-retention-policy)
- [Why is my query with a `WHERE OR` time clause returning empty results?](#why-is-my-query-with-a-where-or-time-clause-returning-empty-results)
- [Why does `fill(previous)` return empty results?](#why-does-fill-previous-return-empty-results)
- [Why are my `INTO` queries missing data?](#why-are-my-into-queries-missing-data)
- [How do I query data with an identical tag key and field key?](#how-do-i-query-data-with-an-identical-tag-key-and-field-key)
- [How do I query data across measurements?](#how-do-i-query-data-across-measurements)
- [Does the order of the timestamps matter?](#does-the-order-of-the-timestamps-matter)
- [How do I `SELECT` data with a tag that has no value?](#how-do-i-select-data-with-a-tag-that-has-no-value)
- [How do I write integer field values?](#how-do-i-write-integer-field-values)
- [How does InfluxDB handle duplicate points?](#how-does-influxdb-handle-duplicate-points)
- [What newline character does the InfluxDB API require?](#what-newline-character-does-the-influxdb-api-require)
- [What words and characters should I avoid when writing data to InfluxDB?](#what-words-and-characters-should-i-avoid-when-writing-data-to-influxdb)
- [When should I single quote and when should I double quote when writing data?](#when-should-i-single-quote-and-when-should-i-double-quote-when-writing-data)
- [Does the precision of the timestamp matter?](#does-the-precision-of-the-timestamp-matter)
- [What are the configuration recommendations and schema guidelines for writing sparse, historical data?](#what-are-the-configuration-recommendations-and-schema-guidelines-for-writing-sparse-historical-data)
On System V operating systems logs are stored under `/var/log/influxdb/`.
On systemd operating systems you can access the logs using `journalctl`.
Use `journalctl -u influxdb` to view the logs in the journal or `journalctl -u influxdb > influxd.log` to print the logs to a text file. With systemd, log retention depends on your system's journald settings.
## What is the relationship between shard group durations and retention policies?
InfluxDB stores data in shard groups.
A single shard group covers a specific time interval; InfluxDB determines that time interval by looking at the `DURATION` of the relevant retention policy (RP).
The table below outlines the default relationship between the `DURATION` of an RP and the time interval of a shard group:
| RP duration | Shard group interval |
|---|---|
| <2days|1hour|
| >= 2 days and <= 6 months | 1 day |
| > 6 months | 7 days |
Users can also configure the shard group duration with the
Second, altering both the `DURATION` and `SHARD DURATION` of an RP can result in
unexpected data retention.
InfluxDB stores data in shard groups which cover a specific RP and time
interval.
When InfluxDB enforces an RP it drops entire shard groups, not individual data
points.
InfluxDB cannot divide shard groups.
If the RP's new `DURATION` is less than the old `SHARD DURATION` and InfluxDB is
currently writing data to one of the old, longer shard groups, the system is
forced to keep all of the data in that shard group.
This occurs even if some of the data in that shard group are outside of the new
`DURATION`.
InfluxDB will drop that shard group once all of its data is outside the new
`DURATION`.
The system will then begin writing data to shard groups that have the new,
shorter `SHARD DURATION` preventing any further unexpected data retention.
## Why does InfluxDB fail to parse microsecond units in the configuration file?
The syntax for specifying microsecond duration units differs for [configuration](/influxdb/v1.8/administration/config/) settings, writes, queries, and setting the precision in the InfluxDB [Command Line Interface](/influxdb/v1.8/tools/shell/) (CLI).
The table below shows the supported syntax for each category:
| | Configuration File | InfluxDB API Writes | All Queries | CLI Precision Command |
|---|---|---|---|---|
| u | ❌ | 👍 | 👍 | 👍 |
| us | 👍 | ❌ | ❌ | ❌ |
| µ | ❌ | ❌ | 👍 | ❌ |
| µs | 👍 | ❌ | ❌ | ❌ |
If a configuration option specifies the `u` or `µ` syntax, InfluxDB fails to start and reports the following error in the logs:
```
run: parse config: time: unknown unit [µ|u] in duration [<integer>µ|<integer>u]
```
## Does InfluxDB have a file system size limit?
InfluxDB works within file system size restrictions for Linux and Windows POSIX. Some storage providers and distributions have size restrictions; for example:
- Amazon EBS volume limits size to ~16TB
- Linux ext3 file system limits size ~16TB
- Linux ext4 file system limits size to ~1EB (with file size limit ~16TB)
If you anticipate growing over 16TB per volume/file system, we recommend finding a provider and distribution that supports your storage requirements.
## How do I use the InfluxDB CLI to return human readable timestamps?
When you first connect to the CLI, specify the [rfc3339](https://www.ietf.org/rfc/rfc3339.txt) precision:
```bash
influx -precision rfc3339
```
Alternatively, specify the precision once you’ve already connected to the CLI:
```bash
$ influx
Connected to http://localhost:8086 version 0.xx.x
InfluxDB shell 0.xx.x
> precision rfc3339
>
```
Check out [CLI/Shell](/influxdb/v1.8/tools/shell/) for more useful CLI options.
## How can a non-admin user `USE` a database in the InfluxDB CLI?
In versions prior to v1.3, [non-admin users](/influxdb/v1.8/administration/authentication_and_authorization/#user-types-and-privileges) could not execute a `USE <database_name>` query in the CLI even if they had `READ` and/or `WRITE` permissions on that database.
Starting with version 1.3, non-admin users can execute the `USE <database_name>` query for databases on which they have `READ` and/or `WRITE` permissions.
If a non-admin user attempts to `USE` a database on which the user doesn't have `READ` and/or `WRITE` permissions, the system returns an error:
```
ERR: Database <database_name> doesn't exist. Run SHOW DATABASES for a list of existing databases.
> **Note** that the [`SHOW DATABASES` query](/influxdb/v1.8/query_language/explore-schema/#show-databases) returns only those databases on which the non-admin user has `READ` and/or `WRITE` permissions.
## How do I write to a non-DEFAULT retention policy with the InfluxDB CLI?
Use the syntax `INSERT INTO [<database>.]<retention_policy> <line_protocol>` to write data to a non-`DEFAULT` retention policy using the CLI.
(Specifying the database and retention policy this way is only allowed with the CLI.
Writes over HTTP must specify the database and optionally the retention policy with the `db` and `rp` query parameters.)
For example:
```
> INSERT INTO one_day mortality bool=true
Using retention policy one_day
> SELECT * FROM "mydb"."one_day"."mortality"
name: mortality
---------------
time bool
2016-09-13T22:29:43.229530864Z true
```
Note that you will need to fully qualify the measurement to query data in the non-`DEFAULT` retention policy. Fully qualify the measurement with the syntax:
You can cancel a long-running interactive query from the CLI using `Ctrl+C`. To stop other long-running query that you see when using the [`SHOW QUERIES`](/influxdb/v1.3/query_language/spec/#show-queries) command,
For example, `SELECT * FROM "hamlet" WHERE "bool"=True` returns all points with `bool` set to `TRUE`, but `SELECT * FROM "hamlet" WHERE "bool"=T` returns nothing.
See [Go builtins](http://golang.org/pkg/builtin/#int64) for more information.
Values close to but within those limits may lead to unexpected results; some functions and operators convert the int64 data type to float64 during calculation which can cause overflow issues.
## What are the minimum and maximum timestamps that InfluxDB can store?
The minimum timestamp is `-9223372036854775806` or `1677-09-21T00:12:43.145224194Z`.
The maximum timestamp is `9223372036854775806` or `2262-04-11T23:47:16.854775806Z`.
Timestamps outside that range return a [parsing error](/influxdb/v1.8/troubleshooting/errors/#unable-to-parse-time-outside-range).
## How can I tell what type of data is stored in a field?
[shard](/influxdb/v1.8/concepts/glossary/#shard) but they can differ across
shards.
Users looking to change a field's data type can use the `SHOW SHARDS` query
to identify the `end_time` of the current shard.
InfluxDB will accept writes with a different data type to an existing field if the point has a timestamp
that occurs after that `end_time`.
Note that this will not change the field's data type on prior shards.
For how this will affect your queries, please see
[How does InfluxDB handle field type discrepancies across shards](/influxdb/v1.8/troubleshooting/frequently-asked-questions/#how-does-influxdb-handle-field-type-discrepancies-across-shards).
## How do I perform mathematical operations within a function?
Currently, InfluxDB does not support mathematical operations within functions.
## Why does my query return epoch 0 as the timestamp?
In InfluxDB, epoch 0 (`1970-01-01T00:00:00Z`) is often used as a null timestamp equivalent.
If you request a query that has no timestamp to return, such as an aggregation function with an unbounded time range, InfluxDB returns epoch 0 as the timestamp.
## Which InfluxQL functions support nesting?
The following InfluxQL functions support nesting:
* [`COUNT()`](/influxdb/v1.8/query_language/functions/#count) with [`DISTINCT()`](/influxdb/v1.8/query_language/functions/#distinct)
* [`HOLT_WINTERS()`](/influxdb/v1.8/query_language/functions/#holt-winters) and [`HOLT_WINTERS_WITH_FIT()`](/influxdb/v1.8/query_language/functions/#holt-winters)
For information on how to use a subquery as a substitute for nested functions, see
- [No field key in the SELECT clause](#no-field-key-in-the-select-clause) (no data returned)
- [SELECT query includes `GROUP BY time()`](#select-query-includes-group-by-time) (partial data before `now()` returned)
- [Tag and field key with the same name](#tag-and-field-key-with-the-same-name)
### Querying the wrong retention policy
InfluxDB automatically queries data in a database’s `DEFAULT` retention policy](/influxdb/v1.8/concepts/glossary/#retention-policy-rp) (RP). If your data is stored in another RP, you must specify the RP in your query to get results.
A query requires at least one [field key](/influxdb/v1.8/concepts/glossary/#field-key) in the `SELECT` clause. If the `SELECT` clause includes only [tag keys](/influxdb/v1.8/concepts/glossary/#tag-key), the query returns an empty response. For more information, see [Data exploration](/influxdb/v1.8/query_language/explore-data/#common-issues-with-the-select-statement).
If your `SELECT` query includes a [`GROUP BY time()` clause](/influxdb/v1.8/query_language/explore-data/#group-by-time-intervals), only data points between `1677-09-21 00:12:43.145224194` and [`now()`](/influxdb/v1.8/concepts/glossary/#now) are returned. Therefore, if any of your data points occur after `now()`, specify [an alternative upper bound](/influxdb/v1.8/query_language/explore-data/#time-syntax) in your time interval.
(By default, most [`SELECT` queries](/influxdb/v1.8/query_language/explore-data/#the-basic-select-statement) query data with timestamps between `1677-09-21 00:12:43.145224194` and `2262-04-11T23:47:16.854775806Z` UTC.)
Avoid using the same name for a tag and field key. If you inadvertently add the same name for a tag and field key, and then query both keys together, the query results show the second key queried (tag or field) appended with `_1` (also visible as the column header in Chronograf). To query a tag or field key appended with `_1`, you **must drop** the appended `_1`**and include** the syntax `::tag` or `::field`.
4. If you query the `grape` measurement, you'll see the `leaves` tag key has an appended `_1`:
```bash
# query the `grape` measurement
SELECT * FROM <database_name>.<retention_policy>."grape"
name: grape
time leaves leaves_1
---- -------- ----------
1574128162128468000 6.00 species
1574128238044155000 5.00
```
5. To query a duplicate key name, you **must drop**`_1`**and include**`::tag` or `::field` after the key:
```bash
# query duplicate keys using the correct syntax
SELECT "leaves"::tag, "leaves"::field FROM <database_name>.<retention_policy>."grape"
name: grape
time leaves leaves_1
---- -------- ----------
1574128162128468000 species 6.00
1574128238044155000 5.00
```
Therefore, queries that reference `leaves_1` don't return values.
{{% warn %}}**Warning:** If you inadvertently add a duplicate key name, follow the steps below to [remove a duplicate key](#remove-a-duplicate-key). Because of memory requirements, if you have large amounts of data, we recommend chunking your data (while selecting it) by a specified interval (for example, date range) to fit the allotted memory.
2. Use the following queries to remove a duplicate key.
```sql
/* select each field key to keep in the original measurement and send to a temporary
measurement; then, group by the tag keys to keep (leave out the duplicate key) */
SELECT "field_key","field_key2","field_key3"
INTO <temporary_measurement> FROM <original_measurement>
WHERE <daterange> GROUP BY "tag_key","tag_key2","tag_key3"
/* verify the field keys and tags keys were successfully moved to the temporary
measurement */
SELECT * FROM "temporary_measurement"
/* drop original measurement (with the duplicate key) */
DROP MEASUREMENT "original_measurement"
/* move data from temporary measurement back to original measurement you just dropped */
SELECT * INTO "original_measurement" FROM "temporary_measurement" GROUP BY *
/* verify the field keys and tags keys were successfully moved back to the original
measurement */
SELECT * FROM "original_measurement"
/* drop temporary measurement */
DROP MEASUREMENT "temporary_measurement"
```
## Why don't my GROUP BY time() queries return timestamps that occur after now()?
Most `SELECT` statements have a default time range between [`1677-09-21 00:12:43.145224194` and `2262-04-11T23:47:16.854775806Z` UTC](#what-are-the-minimum-and-maximum-timestamps-that-influxdb-can-store).
## Can I perform mathematical operations against timestamps?
Currently, it is not possible to execute mathematical operators against timestamp values in InfluxDB.
Most time calculations must be carried out by the client receiving the query results.
There is limited support for using InfluxQL functions against timestamp values.
The function [ELAPSED()](/influxdb/v1.8/query_language/functions/#elapsed)
returns the difference between subsequent timestamps in a single field.
## Can I identify write precision from returned timestamps?
InfluxDB stores all timestamps as nanosecond values, regardless of the write precision supplied.
It is important to note that when returning query results, the database silently drops trailing zeros from timestamps which obscures the initial write precision.
In the example below, the tags `precision_supplied` and `timestamp_supplied` show the time precision and timestamp that the user provided at the write.
Because InfluxDB silently drops trailing zeros on returned timestamps, the write precision is not recognizable in the returned timestamps.
## When should I single quote and when should I double quote in queries?
Single quote string values (for example, tag values) but do not single quote identifiers (database names, retention policy names, user names, measurement names, tag keys, and field keys).
Double quote identifiers if they start with a digit, contain characters other than `[A-z,0-9,_]`, or if they are an [InfluxQL keyword](https://github.com/influxdata/influxql/blob/master/README.md#keywords).
Double quotes are not required for identifiers if they don't fall into one of
those categories but we recommend double quoting them anyway.
Examples:
Yes: `SELECT bikes_available FROM bikes WHERE station_id='9'`
Yes: `SELECT "bikes_available" FROM "bikes" WHERE "station_id"='9'`
Yes: `SELECT MIN("avgrq-sz") AS "min_avgrq-sz" FROM telegraf`
Yes: `SELECT * from "cr@zy" where "p^e"='2'`
No: `SELECT 'bikes_available' FROM 'bikes' WHERE 'station_id'="9"`
No: `SELECT * from cr@zy where p^e='2'`
Single quote date time strings. InfluxDB returns an error (`ERR: invalid
operation: time and *influxql.VarRef are not compatible`) if you double quote
a date time string.
Examples:
Yes: `SELECT "water_level" FROM "h2o_feet" WHERE time > '2015-08-18T23:00:01.232000000Z' AND time < '2015-09-19'`
No: `SELECT "water_level" FROM "h2o_feet" WHERE time > "2015-08-18T23:00:01.232000000Z" AND time < "2015-09-19"`
We [create](/influxdb/v1.8/query_language/manage-database/#create-retention-policies-with-create-retention-policy) a new `DEFAULT` RP (`two_hour`) and perform the same query:
## Why does `fill(previous)` return empty results?
`fill(previous)` doesn't fill the result for a time bucket if the previous value is outside the query's time range.
In the following example, InfluxDB doesn't fill the `2016-07-12T16:50:20Z`-`2016-07-12T16:50:30Z` time bucket with the results from the `2016-07-12T16:50:00Z`-`2016-07-12T16:50:10Z` time bucket because the query’s time range does not include the earlier time bucket.
Raw data:
```sql
> SELECT * FROM "cupcakes"
name: cupcakes
--------------
time chocolate
2016-07-12T16:50:00Z 3
2016-07-12T16:50:10Z 2
2016-07-12T16:50:40Z 12
2016-07-12T16:50:50Z 11
```
`GROUP BY time()` query:
```sql
> SELECT max("chocolate") FROM "cupcakes" WHERE time >= '2016-07-12T16:50:20Z' AND time <= '2016-07-12T16:51:10Z' GROUP BY time(20s) fill(previous)
name: cupcakes
--------------
time max
2016-07-12T16:50:20Z
2016-07-12T16:50:40Z 12
2016-07-12T16:51:00Z 12
```
While this is the expected behavior of `fill(previous)`, an [open feature request](https://github.com/influxdata/influxdb/issues/6878) on GitHub proposes that `fill(previous)` should fill results even when previous values fall outside the query’s time range.
## Why are my INTO queries missing data?
By default, `INTO` queries convert any tags in the initial data to fields in
the newly written data.
This can cause InfluxDB to overwrite [points](/influxdb/v1.8/concepts/glossary/#point) that were previously differentiated by a tag.
Include `GROUP BY *` in all `INTO` queries to preserve tags in the newly written data.
Note that this behavior does not apply to queries that use the [`TOP()`](/influxdb/v1.8/query_language/functions/#top) or [`BOTTOM()`](/influxdb/v1.8/query_language/functions/#bottom) functions.
See the [`TOP()`](/influxdb/v1.8/query_language/functions/#top-tags-and-the-into-clause) and [`BOTTOM()`](/influxdb/v1.8/query_language/functions/#bottom-tags-and-the-into-clause) documentation for more information.
#### Example
##### Initial data
The `french_bulldogs` measurement includes the `color` tag and the `name` field.
```sql
> SELECT * FROM "french_bulldogs"
name: french_bulldogs
---------------------
time color name
2016-05-25T00:05:00Z peach nugget
2016-05-25T00:05:00Z grey rumple
2016-05-25T00:10:00Z black prince
```
##### `INTO` query without `GROUP BY *`
An `INTO` query without a `GROUP BY *` clause turns the `color` tag into
a field in the newly written data.
In the initial data the `nugget` point and the `rumple` points are differentiated only by the `color` tag.
Once `color` becomes a field, InfluxDB assumes that the `nugget` point and the
`rumple` point are duplicate points and it overwrites the `nugget` point with
> SELECT * FROM "candied" WHERE "almonds"::field > 51
name: candied
-------------
time almonds almonds_1 half_almonds
2016-06-07T16:40:20Z 55 true 56
```
##### Specify that the key is a tag:
```sql
> SELECT * FROM "candied" WHERE "almonds"::tag='true'
name: candied
-------------
time almonds almonds_1 half_almonds
2016-06-07T16:40:10Z 50 true 51
2016-06-07T16:40:20Z 55 true 56
```
## How do I query data across measurements?
Currently, there is no way to perform cross-measurement math or grouping.
All data must be under a single measurement to query it together.
InfluxDB is not a relational database and mapping data across measurements is not currently a recommended [schema](/influxdb/v1.8/concepts/glossary/#schema).
See GitHub Issue [#3552](https://github.com/influxdata/influxdb/issues/3552) for a discussion of implementing JOIN in InfluxDB.
## Does the order of the timestamps matter?
No.
Our tests indicate that there is a only a negligible difference between the times
it takes InfluxDB to complete the following queries:
```sql
SELECT ... FROM ... WHERE time > 'timestamp1' AND time < 'timestamp2'
SELECT ... FROM ... WHERE time < 'timestamp2' AND time > 'timestamp1'
```
## How do I SELECT data with a tag that has no value?
Specify an empty tag value with `''`. For example:
```sql
> SELECT * FROM "vases" WHERE priceless=''
name: vases
-----------
time origin priceless
2016-07-20T18:42:00Z 8
```
## Why does series cardinality matter?
InfluxDB maintains an in-memory index of every [series](/influxdb/v1.8/concepts/glossary/#series) in the system. As the number of unique series grows, so does the RAM usage. High [series cardinality](/influxdb/v1.8/concepts/glossary/#series-cardinality) can lead to the operating system killing the InfluxDB process with an out of memory (OOM) exception. See [SHOW CARDINALITY](/influxdb/v1.8/query_language/spec/#show-cardinality) to learn about the InfluxSQL commands for series cardinality.
## How can I remove series from the index?
To reduce series cardinality, series must be dropped from the index.
[`DROP MEASUREMENT`](/influxdb/v1.8/query_language/manage-database/#delete-measurements-with-drop-measurement), and
[`DROP SERIES`](/influxdb/v1.8/query_language/manage-database/#drop-series-from-the-index-with-drop-series) will all remove series from the index and reduce the overall series cardinality.
> **Note:** `DROP` commands are usually CPU-intensive, as they frequently trigger a TSM compaction. Issuing `DROP` queries at a high frequency may significantly impact write and other query throughput.
## How do I write integer field values?
Add a trailing `i` to the end of the field value when writing an integer.
If you do not provide the `i`, InfluxDB will treat the field value as a float.
Writes an integer: `value=100i`
Writes a float: `value=100`
## How does InfluxDB handle duplicate points?
A point is uniquely identified by the measurement name, [tag set](/influxdb/v1.8/concepts/glossary/#tag-set), and timestamp.
If you submit a new point with the same measurement, tag set, and timestamp as an existing point, the field set becomes the union of the old field set and the new field set, where any ties go to the new field set.
This is the intended behavior.
For example:
Old point: `cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000`
New point: `cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000000`
After you submit the new point, InfluxDB overwrites `val_1` with the new field value and leaves the field `val_2` alone:
```sql
> SELECT * FROM "cpu_load" WHERE time = 1234567890000000
name: cpu_load
--------------
time az hostname val_1 val_2
1970-01-15T06:56:07.89Z us_west server02 5.24 7
```
To store both points:
* Introduce an arbitrary new tag to enforce uniqueness.
Old point: `cpu_load,hostname=server02,az=us_west,uniq=1 val_1=24.5,val_2=7 1234567890000000`
New point: `cpu_load,hostname=server02,az=us_west,uniq=2 val_1=5.24 1234567890000000`
After writing the new point to InfluxDB:
```sql
> SELECT * FROM "cpu_load" WHERE time = 1234567890000000
name: cpu_load
--------------
time az hostname uniq val_1 val_2
1970-01-15T06:56:07.89Z us_west server02 1 24.5 7
1970-01-15T06:56:07.89Z us_west server02 2 5.24
```
* Increment the timestamp by a nanosecond.
Old point: `cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000`
New point: `cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000001`
After writing the new point to InfluxDB:
```sql
> SELECT * FROM "cpu_load" WHERE time >= 1234567890000000 and time <= 1234567890000001
## What newline character does the InfluxDB API require?
The InfluxDB line protocol relies on line feed (`\n`, which is ASCII `0x0A`) to indicate the end of a line and the beginning of a new line. Files or data that use a newline character other than `\n` will result in the following errors: `bad timestamp`, `unable to parse`.
Note that Windows uses carriage return and line feed (`\r\n`) as the newline character.
## What words and characters should I avoid when writing data to InfluxDB?
### InfluxQL keywords
If you use an [InfluxQL keyword](https://github.com/influxdata/influxql/blob/master/README.md#keywords) as an identifier you will need to double quote that identifier in every query.
This can lead to [non-intuitive errors](/influxdb/v1.8/troubleshooting/errors/#error-parsing-query-found-expected-identifier-at-line-char).
Identifiers are continuous query names, database names, field keys, measurement names, retention policy names, subscription names, tag keys, and user names.
InfluxDB rejects writes with `time` as a field key or tag key and returns an error.
#### Examples
##### Write `time` as a measurement and query it
```sql
> INSERT time value=1
> SELECT * FROM time
name: time
time value
---- -----
2017-02-07T18:28:27.349785384Z 1
```
`time` is a valid measurement name in InfluxDB.
##### Write `time` as a field key and attempt to query it
```sql
> INSERT mymeas time=1
ERR: {"error":"partial write: invalid field name: input field \"time\" on measurement \"mymeas\" is invalid dropped=1"}
```
`time` is not a valid field key in InfluxDB.
The system does does not write the point and returns a `400`.
##### Write `time` as a tag key and attempt to query it
```sql
> INSERT mymeas,time=1 value=1
ERR: {"error":"partial write: invalid tag key: input tag \"time\" on measurement \"mymeas\" is invalid dropped=1"}
```
`time` is not a valid tag key in InfluxDB.
The system does does not write the point and returns a `400`.
### Characters
To keep regular expressions and quoting simple, avoid using the following characters in identifiers:
`\` backslash
`^` circumflex accent
`$` dollar sign
`'` single quotation mark
`"` double quotation mark
`=` equal sign
`,` comma
## When should I single quote and when should I double quote when writing data?
* Avoid single quoting and double quoting identifiers when writing data via the line protocol; see the examples below for how writing identifiers with quotes can complicate queries.
Identifiers are database names, retention policy names, user names, measurement names, tag keys, and field keys.
Write with a double-quoted measurement: `INSERT "bikes" bikes_available=3`
Applicable query: `SELECT * FROM "\"bikes\""`
Write with a single-quoted measurement: `INSERT 'bikes' bikes_available=3`
Applicable query: `SELECT * FROM "\'bikes\'"`
Write with an unquoted measurement: `INSERT bikes bikes_available=3`
Applicable query: `SELECT * FROM "bikes"`
* Double quote field values that are strings.
Write: `INSERT bikes happiness="level 2"`
Applicable query: `SELECT * FROM "bikes" WHERE "happiness"='level 2'`
* Special characters should be escaped with a backslash and not placed in quotes.
Write: `INSERT wacky va\"ue=4`
Applicable query: `SELECT "va\"ue" FROM "wacky"`
For more information , see [Line protocol](/influxdb/v1.8/write_protocols/).
## Does the precision of the timestamp matter?
Yes.
To maximize performance, use the coarsest possible timestamp precision when writing data to InfluxDB.
In the following two examples, the first request uses a default precision of nanoseconds while the second example sets the precision to seconds:
The tradeoff is that identical points with duplicate timestamps, more likely to occur as precision gets coarser, may overwrite other points.
## What are the configuration recommendations and schema guidelines for writing sparse, historical data?
For users who want to write sparse, historical data to InfluxDB, InfluxData recommends:
First, lengthening your [retention policy](/influxdb/v1.8/concepts/glossary/#retention-policy-rp)‘s [shard group](/influxdb/v1.8/concepts/glossary/#shard-group) duration to cover several years.
The default shard group duration is one week and if your data cover several hundred years – well, that’s a lot of shards!
Having an extremely high number of shards is inefficient for InfluxDB.
Increase the shard group duration for your data’s retention policy with the [`ALTER RETENTION POLICY` query](/influxdb/v1.8/query_language/manage-database/#modify-retention-policies-with-alter-retention-policy).
