Re[2]: Query performance

Got it, can you show both sql requests (with strict and non strict criteria) and EXPLAIN output in both cases ? Do you have indexes?   >Hey, it's enabled already. Please check the console log in my email    >On Thu, 28 Apr 2022, 13:16 Zhenya Stanilovsky, < arzamas...@mail.ru > wrote: >> >>Hi,

Re: Query performance

Hey, it's enabled already. Please check the console log in my email On Thu, 28 Apr 2022, 13:16 Zhenya Stanilovsky, wrote: > > Hi, can you check the same with lazy [1] flag ? > > [1] >

Re: Query performance

Hi, can you check the same with lazy [1] flag ?  [1]  https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/SqlFieldsQuery.html#setLazy-boolean-   >Hi, >We are running a sql field query to fetch 4million records from ignite cache. >We have created a group index for

Query performance

Hi, We are running a sql field query to fetch 4million records from ignite cache. We have created a group index for all fields used in where clause and can see group index used. But the query takes 20 minutes to fetch all records. If we provide more strict criteria to fetch only say 500 records,

Re: Re: SQL query performance with JOIN and ORDER BY or WHERE

DEX(my_index_on_order_by_column)ThanksThomas.On 13.04.21 at 13:10, Taras Ledkov wrote: From: "Taras Ledkov" Date: 13. April 2021To: user@ignite.apache.orgCc: Subject: Re: SQL query performance with JOIN and ORDE

Re: SQL query performance with JOIN and ORDER BY or WHERE

s Kramer wrote: Hi Ilya, unfortunately this also didn't help improving query performance. Not sure what else I can try. Or maybe it is expected? In my opinion it shouldn't take that long as the query without the ORDER BY clause is super fast. Since there is a index on the order field I would

Re: SQL query performance with JOIN and ORDER BY or WHERE

Hi Ilya, unfortunately this also didn't help improving query performance. Not sure what else I can try. Or maybe it is expected? In my opinion it shouldn't take that long as the query without the ORDER BY clause is super fast. Since there is a index on the order field I would expect this should

Re: Re: SQL query performance with JOIN and ORDER BY or WHERE

and WHERE EXISTS, I‘m not familiar with these > statements. > > Thanks! > > > On 09.04.21 at 17:37, Ilya Kasnacheev wrote: > > From: "Ilya Kasnacheev" > Date: 9. April 2021 > To: user@ignite.apache.org > Cc: > Subject: Re: SQL query performance with JOIN and

Re: Re: SQL query performance with JOIN and ORDER BY or WHERE

;Ilya Kasnacheev" Date: 9. April 2021To: user@ignite.apache.orgCc: Subject: Re: SQL query performance with JOIN and ORDER BY or WHERE Hello! ORDER BY will have to sort the whole table. I think that using index on QUEUED will be optimal here. What is the s

Re: SQL query performance with JOIN and ORDER BY or WHERE

Hello! ORDER BY will have to sort the whole table. I think that using index on QUEUED will be optimal here. What is the selectivity of this field? If it s boolean, you might as well use UNION queries. Have you tried joining JOBS via WHERE EXISTS? Regards, -- Ilya Kasnacheev пт, 9 апр. 2021

SQL query performance with JOIN and ORDER BY or WHERE

Hi, I have a SQL performance issue. There are indexes on both fields that are used in the ORDER BY clause and the WHERE clause. The following statement takes about 133941 ms with several warnings from IgniteH2Indexing: SELECT JQ._KEY FROM "JobQueue".JOBQUEUE AS JQ INNER JOIN "Jobs".JOBS AS J ON

RE: Re: Query performance varying with LIMIT keyword

, 2020 7:17 PMTo: user@ignite.apache.orgSubject: Re: Query performance varying with LIMIT keyword Hello, Thanks for responding. Well, it takes 50ms to fetch the first line. What I don't get is why it takes 8 seconds to fetch the 50th line. In both cases I'm only fetching ONE row. I suppose query

Re: Query performance varying with LIMIT keyword

Hello! 200 ms for 2 entries / 1.3s for 11 entries is just 20% increase per entry. Likewise, 7.8s for 51 entries / 1.3s for 11 entries is further 30% increase per entry. It does not sound exponential, at least for any reasonable number of entries, instead it just looks superlinear. I recommend

Re: Query performance varying with LIMIT keyword

Hello, Thanks for responding. Well, it takes 50ms to fetch the first line. What I don't get is why it takes 8 seconds to fetch the 50th line. In both cases I'm only fetching ONE row. I suppose query execution time should be roughly the same whether i want the 1st or the 50th line. I mean,

Re: Query performance varying with LIMIT keyword

Hello! This would suggest that fetching a single row takes around 100 ms, in a slightly superlinear fashion. Why is it a problem? What indexes do you have? Can you provide EXPLAIN plans? Regards, -- Ilya Kasnacheev пн, 20 янв. 2020 г. в 22:23, nunob : > Also if I fix the LIMIT and vary the

Re: Query performance varying with LIMIT keyword

Also if I fix the LIMIT and vary the OFFSET I get responses of this magnitude: LIMIT 1 OFFSET 0: 50ms LIMIT 1 OFFSET 1: 200ms LIMIT 1 OFFSET 5: 700ms LIMIT 1 OFFSET 10: 1.3s LIMIT 1 OFFSET 50: 7.8s Why is this? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Query performance varying with LIMIT keyword

Hello, I have table A with PK (col1, col2, col3) and table B with PK (col1, col2 col3) Both tables have around 300k records. This query executes in *2ms*: /SELECT * FROM table_a a LEFT JOIN table_b b ON b.col1 = a.col1 AND b.col2 = a.col2

Re: Ignite query performance with lots of joins

Hi, Bad news is that there is no short term solution, good news are that the issue/case is acknowledged and that Ignite is moving forward. See approach: https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine -- Sent from:

Re: Ignite query performance with lots of joins

Hi, I checked provided test data. I was able to speedup a query execution with Ignite about 2 times on my machine by using extra configuration property System.setProperty("IGNITE_MAX_INDEX_PAYLOAD_SIZE", "256"); See a following documentation section about configuring index inline size [1]. You

Re: Ignite query performance with lots of joins

Unfortunately, I am nowhere near Silicon Valley these days ;-) Any update on possible optimizations that could bring us somewhat closer than H2 timings? Thanks, L. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite query performance with lots of joins

Ignite SQL engine cannot be considered as a competitor (in a single-node scenario) to old-good RDBMS like Postgres or MySQL. Those DBs have been being developed for decades and are optimized for single-machine deployments. While our efforts (Ignite community) were put into distributed

Re: Ignite query performance with lots of joins

About the quote on Stackoverflow: "Ignite/GridGain is optimized for multi-nodes deployments with RAM as a primary storage. Don’t try to compare a single-node GridGain cluster to a relational database that was optimized for such single-node configurations. You should deploy a multi-node GridGain

Re: Ignite query performance with lots of joins

@Daniel Magda: following you comment on Stackoverflow, continuing the discussion here. This is most probably related to the number of joins, we'll evolve to a less normalized model for querying from Ignite. Couple of questions still remain: - How many joins can Ignite/H2 handle without

Ignite query performance with lots of joins

Hi, I posted a message related to H2 & Ignite performances <https://stackoverflow.com/questions/57902194/h2-ignite-query-performance> on stackoverflow. As the main issue is about a difference in execution times between H2 & Ignite so I thought it would be good to relay it

Re: Ignite Performance - Adding new node is not improving SQL query performance

:* Re: Ignite Performance - Adding new node is not improving SQL query performance Hi! If the new node is not part of the baseline topology it will not have any persisted data stored so any SQL query will not be of any use on the node as it does not have any of the data (at least that is how I

RE: Ignite Performance - Adding new node is not improving SQL query performance

is not improving SQL query performance Hi! If the new node is not part of the baseline topology it will not have any persisted data stored so any SQL query will not be of any use on the node as it does not have any of the data (at least that is how I understand it, I could be wrong here). If so you

Re: Ignite Performance - Adding new node is not improving SQL query performance

Hi! If the new node is not part of the baseline topology it will not have any persisted data stored so any SQL query will not be of any use on the node as it does not have any of the data (at least that is how I understand it, I could be wrong here). If so you would need to add the new node

Ignite Performance - Adding new node is not improving SQL query performance

Hi, I have an ignite cluster with 4 node(each with 8 core, 32 GB RAM and 30 GB Disk) with native persistence enabled and added to baseline topology. There are two sql table created and loaded with 120 GB data. One of my test sql query is taking 8 second with this set up. Currently I am trying

Re: Ignite Select Query Performance

Hi, We can try to check can your configuration be improved but first of all could you please provide some details: 1)How many data nodes you used. 2)Data node configuration 3)Cache configuration or DML Create Table command for your cache (table) BR, Andrei -- Sent from:

Ignite Select Query Performance

Hi, We have inserted a table in Ignite with 10 million rows. The execution time for the following query is around 10 seconds: *select * from tableName offset 500 rows fetch next 100 rows only* The Ignite database was installed on servers with 150 GB RAM. The same table was inserted in

Re: slow query performance against berkley db

Thanks Stan for looking into it. Unfortunately, it still takes 23 sec on 240gb RAM system, the corresponding EXPLAIN PLAN [[SELECT ST.ENTRYID, ST.ATTRNAME, ST.ATTRVALUE, ST.ATTRSTYPE FROM "objectclass".IGNITE_OBJECTCLASS T /* "objectclass".OBJECTCLASSNDEXED_ATTRVAL_IDX:

Re: slow query performance against berkley db

Hi! What is it you are trying to do ? I assume you have a working solution with BDB now, why do you want to change it to Ignite ? do you want/need redundancy/HA ? do you plan to run this on a single node or multiple nodes ? Mikael Den 2018-02-12 kl. 03:45, skrev Rajesh Kishore: Dear all

Re: slow query performance against berkley db

Dear all Request you to kindly suggest me if my approach is wrong ? The idea of replacing berkley db with Ignite would not work out if the query is slow , whats the best model to be used with Ignite for my usecase. Thanks, Rajesh On Fri, Feb 9, 2018 at 9:38 AM, Rajesh Kishore

Re: slow query performance against berkley db

Igniters any pointers pls. Regards, Rajesh On Wed, Feb 7, 2018 at 9:15 AM, Rajesh Kishore wrote: > Hi Dmitry, > > Thanks a ton. > > What is not convincing to me is with just *.1 M in main table and* *2 M > records in other table * , sql query is taking around 24 sec,

Re: slow query performance against berkley db

Hi Dmitry, Thanks a ton. What is not convincing to me is with just *.1 M in main table and* *2 M records in other table * , sql query is taking around 24 sec, that is worrisome. In local cache mode , I tried both using partitioned and non partitioned mode , the result is same. All I wanted to

Re: slow query performance against berkley db

Hi Rajesh, Please allow the community some time to test your code. As far as testing single node vs. distributed, when you have more than one node, Ignite will split your data set evenly across multiple nodes. This means that when running the query, it will be executed on each node on smaller

Re: slow query performance against berkley db

Hi All Please help me in getting the pointers, this is deciding factor for us to further evaluate ignite. Somehow we are not convinced with just . 1 m records it's not responsive as that of Berkley db. Let me know the strategy to be adopted, pointers where I am doing wrong. Thanks Rajesh On 6

Re: slow query performance against berkley db

Further to this, I am re-framing what I have , pls correct me if my approach is correct or not. As of now, using only node as local cache and using native persistence file system. The system has less number of records around *.1 M *in main table and 2 M in supporting table. Using sql to

Re: slow query performance against berkley db

Hi Michael Pls find my response Does that mean Ignite cannot scale well against Berkley dB Incase of single node? Could you please clarify, what your question means? (Rajesh) Our application currently uses Berkley dB and we are using it as key value dB ie storing object as value as bytes, we

Re: slow query performance against berkley db

Rajesh, >Does that mean Ignite cannot scale well against Berkley dB Incase of single node? Could you please clarify, what your question means? Ignite can scale from a single node to hundreds(or even thousands, I have seen the only cluster of 300 nodes, but this definitely not a limit). It was

Re: slow query performance against berkley db

Any pointers please Thanks Rajesh On 5 Feb 2018 10:53 p.m., "Rajesh Kishore" wrote: > Hi Christos > > Does that mean Ignite cannot scale well against Berkley dB Incase of > single node? > > Regards > Rajesh > > On 5 Feb 2018 10:08 p.m., "Christos Erotocritou"

Re: slow query performance against berkley db

Hi Christos Does that mean Ignite cannot scale well against Berkley dB Incase of single node? Regards Rajesh On 5 Feb 2018 10:08 p.m., "Christos Erotocritou" wrote: > Hi Rajesh, > > Ignite is a distributed system, testing with one node is really not the > way. > > You

Re: slow query performance against berkley db

Hi Rajesh, Ignite is a distributed system, testing with one node is really not the way. You need to consider having multiple nodes and portion and collocate your data before. Thanks, C > On 5 Feb 2018, at 16:36, Rajesh Kishore wrote: > > Hi, > > We are in the

slow query performance against berkley db

Hi, We are in the process of evaluating Ignite native persistence against berkely db. For some reason Ignite query does not seem to be performant the way application code behaves against berkley db Background: Berkley db - As of now, we have berkley db for our application and the data is stored

Re: Ignite query performance

Hi, 1. Please, check if index is used for field you use in order by clause. You can check this with EXPLAIN command [1]. If you see wrong index is used, then try hint [2] ignite for proper index. 2. FYI: there is limit and offset in query. For partitioned cache, Ignite will fetch 200 (limit +

Ignite query performance

I'm evaluating apache ignite for a use case very similar to the setup described at - https://dzone.com/articles/apache-ignite-how-to-read-data-from-persistent-sto 1. Instead of Person I'm using Transaction for the proof-of-concept, so I have followed the above link to create 3 source files -

Re: Query performance against table with/out backup

Hi blackfield, I can't reproduce the issue with changing number of backups when cache was re-created. On Fri, Oct 27, 2017 at 8:45 PM, blackfield wrote: > @Andrew Mashenkov, I notice that you opened IGNITE-6781. > However, I actually destroyed the original cache

Re: Query performance against table with/out backup

@Andrew Mashenkov, I notice that you opened IGNITE-6781. However, I actually destroyed the original cache with backup == 1, recreate a new cache with backup ==2 and repopulate the table. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Query performance against table with/out backup

kat...@maxpoint.com> wrote: > Here, I am trying to ascertain that I set backup == 2 properly as I > mentioned > above that I do not see query performance difference between backup ==1 and > backup == 2. > > I want to make sure that I configure my cache properly. > > When I se

Re: Query performance against table with/out backup

occurs. Can you confirm if it is so and recreate cache resolve the issue? On Thu, Oct 19, 2017 at 9:29 PM, blackfield <charles.kat...@maxpoint.com> wrote: > Here, I am trying to ascertain that I set backup == 2 properly as I > mentioned > above that I do not see query performance dif

Re: Query performance against table with/out backup

Here, I am trying to ascertain that I set backup == 2 properly as I mentioned above that I do not see query performance difference between backup ==1 and backup == 2. I want to make sure that I configure my cache properly. When I set the backup==2 (to have three copies), I notice the following

Re: Query performance against table with/out backup

Can you elaborate more on why if there is a scan, Ignite will have to scan the backup as well? Also, it appears adding additional number of backup (backup ==2 instead of 1) does not incur additional performance cost? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Query performance against table with/out backup

Backup copies are stored along with primary copies in the same storage and indexed by same indexes. As a matter of fact, any backup copy can become a primary copy at any moment of time due to topology change. Therefore, if there a scan, the amount of data you have to go through doubles when you

Re: Query performance against table with/out backup

The table is created programmatically, two properties (zone and userId) were marked(annotated) with index = true. When you say, if the index are applied properly to the query, do you mean whether I provide the index hint to the query or else? If the former, the answer is no. The performance

Re: Query performance against table with/out backup

Hi, Do you have indexes configured and (if yes) are they applied properly to the query? Did you check the execution plan? It sounds like your query have to scan the whole cache which gets slower with backups. Can you provide your full cache configuration and data model? -Val -- Sent from:

Query performance against table with/out backup

Hello, We have a table with the following configuration: 1. Persistence is enabled 2. Partition (not replicated) 3. Backup = 1 vs. 0 Everything else, pretty much use default. We have a table in which we perform the following query: SELECT COUNT(*) FROM Table WHERE column1 > 0.75 AND column2 >

Re: Query performance affected by record size?

Hi, Probably you have pretty much data that satisfies the condition. Try running EXPLAIN command to check the query plan. In general, it's better to move child objects into a separate cache and establish a relation via affinity

Re: Query performance affected by record size?

isBenchmark is indexed by the way: @QuerySqlField(index = true) private boolean isBenchmark; -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Query performance affected by record size?

Hi, Could you please share the queries you run against the cache? -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Query performance affected by record size?

I have a use case where I would like to store a record that has some QuerySqlField attributes but also a non-queriable list of child objects. Something like this: public class Portfolio { @QuerySqlField(index = true) private int portCode; @QuerySqlField private String

Re: query performance degrade when adding a filter criteria (order by)

Hi, Did you check execution plans? -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/query-performance-degrade-when-adding-a-filter-criteria-order-by-tp14624p15023.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: query performance degrade when adding a filter criteria (order by)

, neerajbhatt <neerajbhatt2...@gmail.com> wrote: > Also field a in A_CACHE.Rank (r) is indexed > > > > -- > View this message in context: http://apache-ignite-users. > 70518.x6.nabble.com/query-performance-degrade-when- > adding-a-filter-criteria-order-by-tp14624p14625.html

Re: query performance degrade when adding a filter criteria (order by)

Also field a in A_CACHE.Rank (r) is indexed -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/query-performance-degrade-when-adding-a-filter-criteria-order-by-tp14624p14625.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

query performance degrade when adding a filter criteria (order by)

r.uniqueSkuId FROM A_CACHE.Rank as r, B_CACHE.Item as T WHERE T.id = r.id AND r.a=? AND T.b=? AND T.c=? AND T.d=? order by r.rank desc limit 3 Thanks -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/query-performance-degrade-when-adding-a-filter-criteria-order

Re: Issue with SQL Query Performance - Post Rebalance Operation

: http://apache-ignite-users.70518.x6.nabble.com/Issue-with-SQL-Query-Performance-Post-Rebalance-Operation-tp9308p9495.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Issue with SQL Query Performance - Post Rebalance Operation

Thanks, Ganesh -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Issue-with-SQL-Query-Performance-Post-Rebalance-Operation-tp9308p9389.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Issue with SQL Query Performance - Post Rebalance Operation

itself, or probably there is something else that you're missing. -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Issue-with-SQL-Query-Performance-Post-Rebalance-Operation-tp9308p9350.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Issue with SQL Query Performance - Post Rebalance Operation

in context: http://apache-ignite-users.70518.x6.nabble.com/Issue-with-SQL-Query-Performance-Post-Rebalance-Operation-tp9308.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Re: Some problems in test case which comparing sql query performance between Ignite and Oracle

Hi Warm-hearted person， Thanks for your help. According to your advice, I will query some field not using select *. I will add the index in the cache. To Vladislav Pyatkov, In previous mail, you said "you are always can copy data to another cache (with index) and drop this",

Re: Some problems in test case which comparing sql query performance between Ignite and Oracle

Bob, can you please also tell what is your benchmark scenario? Do you have enough warm-up cycles to bring your app to some steady state? --Yakov 2016-10-20 12:40 GMT+03:00 Vladislav Pyatkov : > Hi Bob, > > One way to do SQL faster this is adding indexes. > 1) I do not

Re: Some problems in test case which comparing sql query performance between Ignite and Oracle

Hi Bob, One way to do SQL faster this is adding indexes. 1) I do not think what the estimation will be a lot improve without index. Because of the need to serialize, deserialize and move in network data. 2) Ignite does not create index on existing data, but you are always can copy data to

Re: Some problems in test case which comparing sql query performance between Ignite and Oracle

Bob, 1) Did you create index on Ignite cache? 2) Could you attach you cluster and cache configs? I also agree with Jörn Franke, that such simple query (no joins, simple "where condition") is not very suitable for benchmarking (unless all in your app you are using such queries a lot). --

Re: Some problems in test case which comparing sql query performance between Ignite and Oracle

You have to understand for what the database cache is good: lookups of single/few rows. This is due to the data structure of a cache. In this sense you use the cache wrongly. Aside of this I think select * is really the worst way to do professional performance evaluation of your architecture.

Some problems in test case which comparing sql query performance between Ignite and Oracle

Hi, everyone My test environment: Ignite cluster has 8 nodes, every node has 8 cores CPU and 30G memory. Their network has 1000M speed. Oracle is deployed in the machine which has 32G memory and 8 cores CPU. My db table has 47535542 rows with 99 columns. When no index, the

Re: ignite in-memory sql query performance issue

> *发送时间:* 2016年6月6日 16:10 > *收件人:* user@ignite.apache.org > *主题:* Re: ignite in-memory sql query performance issue > > > > Hi Kevin, > > > > Could you please provide the source code of SelectedClass and estimate > number of entries in the cache? As Vl

re: ignite in-memory sql query performance issue

[mailto:voze...@gridgain.com] 发送时间: 2016年6月6日 16:10 收件人: user@ignite.apache.org 主题: Re: ignite in-memory sql query performance issue Hi Kevin, Could you please provide the source code of SelectedClass and estimate number of entries in the cache? As Vladislav mentioned, most probably this is a matter

re: ignite in-memory sql query performance issue

; } public Date getDate() { return date; } public void setDate(Date date) { this.date = date; } } 发件人: Vladimir Ozerov [mailto:voze...@gridgain.com] 发送时间: 2016年6月6日 16:10 收件人: user@ignite.apache.org 主题: Re: ignite in-memory sql query performance issue Hi Kevin

Re: ignite in-memory sql query performance issue

Hi Kevin, Could you please provide the source code of SelectedClass and estimate number of entries in the cache? As Vladislav mentioned, most probably this is a matter of setting indexes on relevant fields. If you provide the source code, we will be able to give you exact example on how to do

Re: ignite in-memory sql query performance issue

Hello, Do you use indexes in a SQL query? If it does not, that try to create a group index over field1 and fild2. You can find a description here https://apacheignite.readme.io/docs/sql-queries On Mon, Jun 6, 2016 at 5:56 AM, Zhengqingzheng wrote: > Hi there, > >

ignite in-memory sql query performance issue

Hi there, When using sql query to get a list of objects, I find that the performance is really slow. I am wondering, is this normal? I tried to call a sql query as follows: String qryStr = "select * from SelectedClass where field1= ? and field2=?"; SqlQuery qry = new

答复: re: Ignite Sql Query performance problem

[mailto:valentin.kuliche...@gmail.com] 发送时间: 2016年4月11日 13:12 收件人: user@ignite.apache.org 主题: Re: re: Ignite Sql Query performance problem Kevin, Each index add memory overhead. It's hard to estimate without knowing the details of the application, but in general indexes do not add more than 20-30% to the overall

re: Ignite Sql Query performance problem

is the cost for the memory usage? Best regards, Kevin -邮件原件- 发件人: vkulichenko [mailto:valentin.kuliche...@gmail.com] 发送时间: 2016年4月11日 5:54 收件人: user@ignite.apache.org 主题: Re: Ignite Sql Query performance problem Hi, Most likely you don't have indexes and the query has to scan the whole

Re: Ignite Sql Query performance problem

-Query-performance-problem-tp4031p4041.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Ignite Sql Query performance problem

Hi there, I am a new ignite user. I noticed that the sql query performance is much slower that the general cache.get(x) method. In my case, I run a simple query twice: in the first time, I called a sql query 100 times and it toke 235ms( average 23.5ms per sql); in the second time, I called

RE: SQL query performance

Hi Shaomin, If you're doing a benchmark, you should run the code that you're going to measure. The warm up happens on JVM level, it's not about Ignite and its caches at all. -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-query-performance-tp3202p3312

RE: SQL query performance

Subject: Re: SQL query performance Hi Shaomin, Before starting to provide best performance, JVM needs some time to warm up and apply all JIT optimizations. It sounds like you're running the query only once, so this doesn't happen. Do this several times in a loop and you should get 0ms timings

Re: SQL query performance

in context: http://apache-ignite-users.70518.x6.nabble.com/SQL-query-performance-tp3202p3206.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

SQL query performance

Hi All I am doing a SqlFieldQuery on a single cache of around 60 entries on a single Ignite server locally. The query has two parameters and the cache has a compound index of the two parameter field. It takes from 60 to 80 milliseconds to finish, while it takes only 3 milloseconds for the same

Re: Sql query performance with partitioned caches

On Wed, Jan 27, 2016 at 5:34 AM, Andrey Nestrogaev < a.nestrog...@flexsoft.com> wrote: > Denis, > > I don't agree that extra newtork roundtreeps "costs almost nothing" for > heavy OLTP load :) > I disagree, because many large companies, including some very well known banks, use Ignite exactly

Re: Sql query performance with partitioned caches

-- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-with-partitioned-caches-tp2700p2751.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Sql query performance with partitioned caches

for the ID and execute local query there. This way you avoid meaningless network trips to other nodes. Makes sense? -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-with-partitioned-caches-tp2700p2746.html Sent from the Apache Ignite

Re: Sql query performance with partitioned caches

ext: http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-with-partitioned-caches-tp2700p2742.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Sql query performance with partitioned caches

hus it appears that ignite sql inginte with partitioned caches can't scale for OLTP queries (every query runs on every node), it only will good serves for DWH workload? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-with-partitioned-caches-tp2700p2

Re: Sql query performance with partitioned caches

cast on every node. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-with-partitioned-caches-tp2700p2734.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Sql query performance with partitioned caches

capabilities doesn't help. If you have such a use case in mind, the example would be useful. [1] https://apacheignite.readme.io/docs/affinity-collocation -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-with-partitioned-caches-tp2700p2727

Re: Sql query performance with partitioned caches

/Sql-query-performance-with-partitioned-caches-tp2700p2715.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Sql query performance with partitioned caches

that has to be executed on a subset of nodes. -Val -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-with-partitioned-caches-tp2700p2716.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Sql query performance with partitioned caches

pruning based on predicates? Or sql queries are only intended for analitic's queries? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-with-partitioned-caches-tp2700p2706.html Sent from the Apache Ignite Users mailing list archive

Re: Query performance

Cool I let you know about performance. -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Re-Query-performance-tp1009p1192.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Query performance

/value. Any thoughts? -- View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Re-Query-performance-tp1009p1149.html Sent from the Apache Ignite Users mailing list archive at Nabble.com.

  1   2   >