ok, now i found why: the first thing volume tests execute is (simplified)

select timestamp_column
from table
where timestamp_column >= training_period

and only then calculate the

buckets

and only then calculate the

counts

of the above select per

bucket

. would it not be an option to calculate the

buckets

first, and then query the

table

to directly get the

counts

of

timestamp_column

per

bucket

? this way, if

timestamp_column

is a partition (or clustered etc) and its grain is the same as

time_bucket:period

, you would reduce runtime to almost zero. this might have a very noticable effect on companies running a lot of (standard) volume tests.

shameless ping (again) to @Noa Kurman

this seems to be very related (thx @Francesco Mucio for finding)

fyi @Samuel Garfield

ah I accidentally submitted it as a dicussion instead of an issue. New issue here

This one may also be of interest to you @michael böhm

I guess the change needs to be applied here

or actually write a new macro just for the volumes

regular 2-months inquiry, @Noa Kurman 😉

@Itamar Hartstein i see you tentatively closed the related issue from Sam, but at least for us the above isn’t resolved - as in the tests still do not make use of existing table/column optimizations and take many minutes instead of few seconds. would the team still like to address this?

which is now here