This allows the query:
SELECT mean(value) FROM cpu GROUP BY time(1d)
To function in some way that makes sense. The upper limit is implicitly
the `now()` starting time and the lower limit will be whichever interval
the lowest point falls into.
When no lower bound is specified and `max-select-buckets` is specified,
the query will only consider points that would satisfy
`max-select-buckets`. So if you have one point written in 1970, have
another point within the last minute, and then do the above query with
`max-select-buckets` being equal to 10, the older point from 1970 will
not be considered.
The Makefile has not been used by the project since before 1.0 and is
not maintained. Removing it so it doesn't send the wrong signal to
potential developers.
Some files seem to get orphan behind higher levels. This causes
the compactions to get blocked as the lowere level files will not
get picked up by their lower level planners. This allows the full
plan to identify them and pull them into their plans.
The *.1.gz files are included into the source tarball, and the .deb and
.rpm files will now install the man pages when the package is installed.
Fixes#8908.
From the systemd.service docs:
Use "${FOO}" as part of a word, or as a word of its own, on the command
line, in which case it will be replaced by the value of the environment
variable including all whitespace it contains, resulting in a single
argument. Use "$FOO" as a separate word on the command line, in which
case it will be replaced by the value of the environment variable split
at whitespace, resulting in zero or more arguments.
This check doesn't make sense for high cardinality data as the files
typically get big and sparse very quickly. This causes a lot of extra
disk space to be used which is taken up by large indexes and sparse
data.
One shard might be able to run a compaction, but could fail to
limits being hit. This loop would continue indefinitely as the
same task would continue to be rescheduled.
With higher cardinality or larger series keys, the files can roll
over early which causes them to take longer to be compacted by higher
levels. This causes larger disk usage and higher numbers of tsm files
at times.