Filter by reset
- Everywhere
6772 - Issues
1953 - Pull Requests
813 - Comments
4006
Adjusting the regular expression to calculate performance.
done
Queries are slow, about 200 million data points.
This is my configuration, version 3.4.2 runs in docker.CPU 2 core, memory 2G. searchd { listen = 9312 listen = 9308:http listen = 9306:mysql41 log = /var/log/manticore/searchd.log query_log = /var/lib/manticore/data/query.log binlog_path = /var/lib/ …
waitingwontfix
❓ Per-field tokenization (question for the community) ❓
how to search fast with ramchunk(rt table) in High-Frequency Write Systems
I forked benchmarks to https://github.com/abhijo89-uc/benchmarks/ and updated from plain index to rt index. then perform the same test . Its really slow !! Any comments ? Google sheet is : https://docs.google.com/spreadsheets/d/ …
Test Profile-Guided Optimization (PGO)
Performance degradation in b632b/709b9
There are several performance degradations in 20230909 b632b 709b9 (compared to 20230624 75a47 35b04 ). One of them is because I limited maximum threads in all fulltext queries to the number of physical cores. My benchmarks show that most of the time …
est::size_M
Related to #1103
how to search fast with ramchunk(rt table) in High-Frequency Write Systems
Test Profile-Guided Optimization (PGO)
Is your feature request related to a problem? Please describe. Not a problem - just an idea of how to (possibly) improve ManticoreSearch performance. Describe the solution you'd like Recently I did a lot of testing Profile-Guided Optimization (PGO) on …
Feature Request: Different Data Formats
Implement batching inside a join query
Proposal: Currently join works by generating a query to the right table for every match in the left table and storing the result in a cache. If there are a lot of unique join conditions, this is very slow. We could accumulate join conditions for several …
rel::upcoming
waiting
I have an index with 200 full text fields in it. I prepared 3.8 million data, but the data is highly repetitive. It takes 250-300 milliseconds on average to run the following query. create table test (e, s0.....s199) rt_mem_limit='1024m' min_prefix_len = …
6.2.0 gives syntax error, older versions don't
bugest::NO_ESTIMATErel::6.3.0
What are the factors that affect search efficiency?
Want to consult, have those factors to affect search efficiency. Because I've learned from elasticSearch that an index should not be too much larger than available memory, so response times are millisecond level. Does manticore have the same mechanism? …
discussion
est::size_S
how to search fast with ramchunk(rt table) in High-Frequency Write Systems
Confirmation Checklist: You have searched for an answer in the manual. You have considered using the forum for general discussions, which can be more suitable for non-urgent or broad queries. You are aware of our community support channels on Slack, …
how to search fast with ramchunk(rt table) in High-Frequency Write Systems
Manticore 4.0.2 slower than Manticore 3.6.3
…Hi, I have a production 3.6.3 installation and I'm evaluating to migrate to 4.0.2, before this upgrade I'm doing some stressing tests to evaluating performances. Here the steps to compare the results: I started a VM Centos 7 with Manticore 3.6.3 …
Is there a way to apply morphology to the data field in CALL PQ?
bug
Queries on taxi dataset are slow with ps=1
Queries on partial taxi dataset (6 indexes) are almost 2x slower with pseudo_sharding enabled: mysql> set global pseudo_sharding=0; SELECT avg(total_amount) FROM taxi WHERE trip_distance = 5; show meta; Query OK, 0 rows affected (0.00 sec) …
bugrel::6.2.0
Manticore 4.0.2 slower than Manticore 3.6.3
optimize grouping by time further
A query like this is now about 10 times faster than before revamp of the date/time functions, but as discussed there still seems to be room for further optimization: mysql> SELECT year(pickup_datetime) as y, count(*) trips FROM taxi GROUP BY y ORDER BY y …
est::NO_ESTIMATE
select ... join + facet against 2 tables of 277562 and 8671 docs is too slow: snikolaev@dev2:~$ mysql -P9306 -h0 Server version: 6.2.13 8db8be098@24031215 dev (columnar 2.2.5 aa3504b@240304) (secondary 2.2.5 aa3504b@240304) (knn 2.2.5 aa3504b@240304) git …
est::size_Mfeature::join
agent_retry_count does not work with ha_strategy nodeads and noerrors
performance degradation with wildcard queries with many matches when disk_chunks > 1
Bug Description: There is a noticeable decrease in the speed of executing wildcard queries with an index using two or more disk chunks compared to the speed of executing the same queries with the same data using one disk chunk. This issue was not observed …
bugrel::6.3.4
bugwaiting
Is it possible to limit the memory usage of the searchd process
I find that after batch insert data to manticore, the usage of the searchd process not free the memory? This is my config file index hacker_new { type = rt rt_mem_limit = 2048M path = /home/mcsearch/index/hacker_new rt_attr_bigint = story_id rt_attr_ …
waiting
Reduce RAM usage of empty plain indexes
bug
I am using Manticore's plain table to rebuild indexes from PostgreSQL using range queries. Currently, it takes about 70 minutes to process approximately 11 million records, which feels too slow. Can the process be sped up, for example, by utilizing multi- …
Move performance tests to a separate folder, remove unnecessary script
Continued from https://github.com/manticoresoftware/manticoresearch/pull/2588 Deleted one of the scripts, added arguments to the script run. Move performance tests to a separate folder, remove unnecessary script
done
how to search fast with ramchunk(rt table) in High-Frequency Write Systems
Proposal: searchd uses a fair amount of CPU on my server, so I decided to attach perf to see what took most of the time. The following is mostly observations I've made, without having investigated it much, so apologies for lack of details and such. In …
waiting
What are the factors that affect search efficiency?
discussion