Why is my query so slow?

[Hebrh]

I've started GreptimeDB in the standalone mode, connected it with MySQL client, created a database named 'test', and created a table using following statements:
create table test.test_table ( sk_f_prod string, src_secu_code string, ann_date timestamp, price_date timestamp, f_nav_unit double, f_nav_accumulated double, f_nav_divaccumulated double, f_nav_adjfactor double, crncy_code string, f_prt_netasset double, f_asset_mergedsharesornot boolean, netasset_total double, f_nav_adjusted double, is_exdividenddate boolean, f_nav_distribution double, create_dt timestamp DEFAULT CURRENT_TIMESTAMP, update_dt timestamp DEFAULT CURRENT_TIMESTAMP, primary key (src_secu_code), time index (price_date) ) ENGINE=mito WITH(regions=3);

Then I used a sql script to import data into 'test_table' through MySQL client. The insert sql is just like the following statement:
insert into test.test_table values ('PD01121002','121002.OF','2010-07-29 0:00:00','2010-07-28 0:00:00',0.89580000,2.86480000,null,4.27479300,'CNY',null,False,null,3.82935957,False,1.9690,'2023-02-02 15:32:10','2023-02-02 15:32:10');

The number of rows of data in the table 'test_table' is about seventeen million.
Everytime I query the data from MySQL client connecting GreptimeDB using following sql:
SELECT price_date, src_secu_code, f_nav_adjusted FROM test.test_table WHERE price_date > '2021-01-01 0:00:00' AND price_date < '2021-03-01 0:00:00' AND src_secu_code = '090010.OF';
That will always cost about 1.3 second of time.
I'm confused that why is the query so slow? And How can I accelerate the query?

[MichaelScofield]

Did you build GreptimeDB in release mode? i.e. cargo build --release.

I've done some similar benchmarks before, and saw the queries were indeed been executed slowly under debug build. However, performance boosted greatly when I switched to release build.

[Hebrh]

I am using the latest release bianry version
greptime-linux-amd64.tgz

[evenyag]

Even using the release build, there are still many bottlenecks in the system. Our default memtable size is quite small so there might be too many small files to scan and merge. We haven't implemented compaction yet, but we are working on it, in #930 . Unfortunately, the memtable size is unconfigurable now. The file scan performance is also possible to improve. I think we could address some performance issues in the 0.2 release.

[EeroEternal]

when will the 0.2 version be released?
How much performance will be improved, is there a benchmark report to see?
thanks

[killme2008]

The table compaction will be implemented in 0.1 and released around 15th, Feb.
I think we can make memtable size could be configurable too @evenyag .
The 0.2 release will focus on performance, I think it may release in April.

[lipish]

Thanks, Looking forward to performance improvements