I have a one question.
I want to use limit for delete query with querydsl. Is there any way?
delete(wedul).where(wedul.id.eq(10)).limit(10)
JPA (on which hibernate and querydsl is built) does not support something like a limit or rownum for deletes, because it is not a universally supported database concept.
A common approach to solving this would be to delete from the table where the 'id' in contained within a subquery, and the place the limits on the subquery.
See this other answer
Related
I am trying to optimize a very long and complex impala query which contains multiple CTE. Each CTE is used multiple times. My expectation is that once a CTE is created, I should be able to direct impala that results of this CTE should be re-used in main query as-is instead of SCAN HDFS operation on tables involved in CTE again with the main query. Is this possible? if yes how ?
I am using impalad version 2.1.1-cdh5 RELEASE (build 7901877736e29716147c4804b0841afc4ebc9037) version
I do not think so. I believe WITH clause does not create any permanent object, it's just for you avoid cluttering the namespace with new tables or views and to make it easier to refactor large, complex queries by reor‐
dering and replacing their individual parts. The queries used in the WITH clause are good candidates to someday become views or to be materialized as summary tables during the ETL process.
Is this possible?
The very purpose of the CTE is to re-use of the results obtained from a preceding query (that uses the with clause) by a following query, say, SELECT. So i don't see a reason why it is not possible.
Use Explain on your query to find out the actual SCAN HDFS details.
For more I/O related insights use profile as in the official documentation https://www.cloudera.com/documentation/enterprise/5-7-x/topics/impala_explain_plan.html#perf_profile
I have implemented jpa self join relationship in one of my project. We have more than 200k records in this table. I am also using delete orphan annotation. Now when my app tries to delete orphaned entities which has this self join then it is taking too long to delete records in db. Our dba check index and everything else.
Can someone please explain what can cause this performance issue? Looking at the query, I believe it is scanning whole table to verify parent child relation before deleting those records.
For huge tables and self join, usually the simple join queries generated by ORM tools are not performant. To confirm you can log the sql produced by the ORM and then run EXPLAIN PLAN FOR or EXPLAIN (depending upon whether the database is oracle or mysql) and analyse the output. This would give you a fair idea of what is wrong.You might need to actually write an an alternate SQL query and tune it and then use NativeQuery feature of JPA to get the query result effectively.
As far as I understand, when we run SQL query with COUNT, DISTINCT or LIKE %query% (wildcards at both sides) keywords the indexes cannot be used and the database have to do the full table scan.
Is there some way to boost the performance of these queries?
Do they really cannot use indexes or we can fix this somehow?
Can we make an index-only scan if we need to return only one column? For example: select count(id) from MY_TABLE: probably in this case we can make index-only scan and avoid hitting the whole table if we have index on 'id'?
My question has a general meaning: could you give me some performance guidelines if we have to use the mentioned operators?
UPDATE
As for me I use PostgreSQL.
with PostgreSQL, you can create GIN pg_trgm indexes for text strings to make LIKE '%foo%' faster, though this requires addons, and PostgreSQL 9.1 or higher.
I doubt distinct by itself will ever use an index. I tried in fact and could not get it to use one. You can sort of force an index to be used by using a recursive CTE to pull individual records out (what can be called a "sparse scan"). We do something like this when pulling individual years out of the accounting record. This requires writing special queries though and so isn't really the general case.
count(*) is never going to be able to use an index due to mvcc rules. You can get approximate results by looking in the appropriate system catalogs however.
Hi every one,
I have a requirement to get all the views and indexes from Oracle/PostgreSQL DB
Here I have written one query like below to get all views
SELECT * FROM INFORMATION_SCHEMA.VIEWS where table_schema = 'public'
But that is postgreSQL dependent query right. Because in Oracle, information_schema was implemented differently so i thought to write jpql query but i dont know how to write.
Could anybody please help me out!
Thanks & regards,
Sridhar Kosna.
It's not possible. JPQL is only able to query mapped entities. Not database tables. You'll need to use SQL, and if you need to support multiple databases, have one DAO per database and use the appropriate DAO based on the used database.
I would like to apply a Criteria query to an in-memory collection
of entities, instead of on the database. Is this possible?
To have Criteria API work like LINQ? Or alternatively, convert
Criteria query to LINQ query.
Thanks!
I don't believe you can use Criteria to query against an in-memory collection and come to think about it it doesn't seem to make much sense. If I'm understanding everything correctly you've already queried against your database. I'd suggest to either tune your original query (whichever method you choose) to include all of your filters. Or you could use LINQ (as you suggested) to refine your results.
Also, what's your reasoning for wanting to query from memory?
It sounds like you're rolling your own caching mechanism. I would highly recommend checking out NHibernate's 2nd level cache. It handles many complex scenarios gracefully such as invalidating query results on updates to the underlying tables.
http://ayende.com/Blog/archive/2009/04/24/nhibernate-2nd-level-cache.aspx