Why this multiple-measurements query needs 10 seconds?

In windows server 2012R, we using python API, query 50 stocks last ticks data, this query needs over 10 seconds? Shall I change the query to only simple 1 measurement?
the query words:
from(bucket:“tick”) |> range(start: -3h, stop: now()) |> filter(fn: (r) => r._measurement == “002049” or r._measurement == “002079” or r._measurement == “002119” or r._measurement == “002156” or r._measurement == “002180” or r._measurement == “002185” or r._measurement == “002371” or r._measurement == “003026” or r._measurement == “300046” or r._measurement == “300053” or r._measurement == “300077” or r._measurement == “300223” or r._measurement == “300327” or r._measurement == “300346” or r._measurement == “300373” or r._measurement == “300456” or r._measurement == “300458” or r._measurement == “300613” or r._measurement == “300623” or r._measurement == “300661” or r._measurement == “300666” or r._measurement == “300671” or r._measurement == “300672” or r._measurement == “300706” or r._measurement == “300782” or r._measurement == “300831” or r._measurement == “600171” or r._measurement == “600206” or r._measurement == “600360” or r._measurement == “600460” or r._measurement == “600584” or r._measurement == “603005” or r._measurement == “603068” or r._measurement == “603160” or r._measurement == “603290” or r._measurement == “603501” or r._measurement == “603893” or r._measurement == “603986” or r._measurement == “605111” or r._measurement == “605358” or r._measurement == “688008” or r._measurement == “688012” or r._measurement == “688018” or r._measurement == “688037” or r._measurement == “688099” or r._measurement == “688123” or r._measurement == “688126” or r._measurement == “688233” or r._measurement == “688368” or r._measurement == “688396”) |> last() |> timeShift(duration: 8h)

Hello @justin_zhang,
How many measurements do you have total in that bucket?
Are you collecting data at the same interval for all the stocks?
How much data or points do you expect to be returned from all of those measurements for the last 3 hours?

I might have made the id a tag instead of a measurement.

I assume you are using InfluxDB v2 open source?

I’ve actually been working on optimizing this exact kind of query recently for open source, and the optimization should be in place for the next release. It will make these kinds of queries involving multiple measurements much faster. Currently, the storage code defaults to a slower path if there are multiple measurements in the query - and it can be a very dramatic effect if your database has a large number of measurements and/or shards.

1 Like

about 3,000~4,000 different stocks in the bucket, each stock is a measurement.
I think the qery is slow is because of the compression method, because this method needs former data to recover the original data, and because different stocks has different value range, so I put one stock into one measurements.
Three hours data for each stock commonly includes 3,600 points. In fact the time cost of query 10 minutes almost same with query 1 hour data.

Yes, thanks, whether this situation will not happen in v1.7 open source?