My manger just told me that having joins or where clause in oracle query doesn't affect performance even when you have million records in each table. And I am just not satisfied with this and want to confirm that.
which of the following queries is better in performance on oracle and in postgresql also
1- select a.name,b.salary,c.address
from a,b,c
where a.id=b.id and a.id=c.id;
2- select a.name,b.salary,c.address
from a
JOIN b on a.id=b.id
JOIN C on a.id=c.id;
I have tried Explain in postgresql for a small data set and query time was same (may be because I have just few rows) and right now I have no access to oracle and actual database to analyze the Explain in real envoirnment.
Using JOINS makes the code easier to read, since it's self-explanatory.
In speed there is no difference (I have just tested it) and the execution plan is the same
If the query optimizer is doing its job right, there should be no difference between those queries.
They are just two ways to specify the same desired result.
Related
I am looking for performance improvement of SQL (ORACLE)
Based on few examples I tried to compare execution time between simple join between two tables v/s same query with MatrializedView.
Both execution time is almost same.
TableA Join TableB
V/s
CREATE MATERIALIZED VIEW emp_mv
BUILD IMMEDIATE
REFRESH FORCE
ON DEMAND
AS (QUERY TableA Join TableB)
both sqls are running for 7m for 1000 records.
total we have 14k Records in Table A and 50 recoreds in Table B , final output with 14K records
Is there anything which I am missing regarding performance of query execution?
Why would you expect the same query to act differently?
Materialized view's benefit might come later, when you actually start using data it contains because you already pre-processed it and prepared for future use. You could use the same query (with the join) over and over again and it'll take more or less the same time (disregard caching). But, if you store that query's data into a materialized view (and properly index it), data retrieval might/should be faster.
That's kind of "opposite" of creating an ordinary view which doesn't contain any data - it is just a stored query and it retrieves data every time you select from it, performing the same join all over again.
Materialized view contains data, just as if it were a table. It helps a lot if data is stored in tables you access over database links - that might be, and usually is, slow. But, if you create a materialized view (during night/off hours), you have data available to you much faster. It won't help much if data in tables change frequently because you'll have to refresh the MV frequently as well (usually ON COMMIT), but - if tables are really large, you have a complex query, then refreshing might also take some (a lot of?) time.
When I get the autotrace output of the query above using the Oracle SQL Developer, I see that the join condition is used for access and filter predicates. My question is, does it read all the department_ids from the DEPT_ID_PK and then use these IDs to access and filter the employees table? If so, why the employees table has full table scan? Why does it read the employees table again by using the department_ids of the departments table? Could anyone please read this execution plan step by step simply, and explain the reason why the access and filter predicates are used here?
Best Regards
it is a merge join (a bit like hash join, Merge join is used when projections of the joined tables are sorted on the join columns. Merge joins are faster and uses less memory than hash joins).
so Oracle do a full table scan of in outer table (EMPLOYEES) and the it read the inner table in a ordred manner.
the filtre predicates is the column on which the projection will be done
more details: https://datacadamia.com/db/oracle/merge_join
It uses the primary key to avoid sorting, otherwise the plan would be like this
The distinction between "Access predicates" and "Filter predicates" is not particularly consistent, so take them with healthy amount of skepticism. For example, if you remove the USE_MERGE hint, then there would be no Fiter Predicates in the plan any more, and the Access Predicates node would be relocated under the HASH_JOIN node (where it makes more sense for MERGE_JOIN as well):
I am concerned about the below queries:
select * from TABLEA where COLUMNA in (select....) and
COLUMNA in (select....)
delete from TABLEA where COLUMNA in (select....) and
COLUMNA in (select....)
Both have huge differences in running time.
The select query runs much faster than a similar delete query.
SELECT is just a PROJECTION. SELECT with FILTER PREDICATE is SELECTION. And both are completely different from DELETE, which is a DML.
Your question is too broad as it involves lot of stuff.
Select statement doesn't manipulate the data, DML does.
Select doesn't update the index keys, DML does.
DB writers are not involved with select, but with DML.
The OPTIMIZER acts differently for DIFFERENT OPERATIONS. Look at the explain plan at least.
...and many more reasons.
Two different contexts, no point in comparing.
GUI ISSUES
A select might look like faster when executed on GUI based tools like SQL Developer etc. which actually shows you the first fetched rows and not complete resultset. However, the DELETE needs to actually act on all the rows.
Please check table structure and indexes. Maybe there a lot of ON DELETE CASCADE constraints or a lot of indices to delete. Indicies speed up select time and slow down delete time.
I have over million records in these tables in both the databases.
I am trying to figure out data in both the tables acros databases.
SELECT COUNT(*) FROM DB1.MYTABLE WHERE SEQ_NO NOT IN(SELECT SEQ_NO FROM DB2.MYTABLE) AND FILENAME NOT LIKE '%{%'
and PT_TYPE NOT IN(15,24,268,284,285,286,12,17,9,290,214,73) AND STTS=1
The query is taking ages. Is there any way I can make it fast?
Appreciate your help in advance
Do you actually mean different databases? Or do you mean different schemas? You talk about different databases but the syntax appears to be using tables in two different schemas, not two different databases. I don't see any references to a database link which would be needed if there were two different databases but perhaps DB2.MYTABLE is supposed to be a synonym for MYTABLE#DB2.
It would be helpful if you could post the query plan that is generated. It would also be useful to indicate what indexes exist and how selective each of these predicates is. My guess is that modifying the query to be
SELECT count(*)
FROM schema1.mytable a
WHERE NOT EXISTS (
SELECT 1
FROM schema2.mytable b
WHERE a.seq_no = b.seq_no )
AND a.filename NOT LIKE '%{%'
AND a.pt_type NOT IN (15,24,268,284,285,286,12,17,9,290,214,73)
AND a.stts = 1
might be more efficient if most of the rows in SCHEMA1.MYTABLE are eliminated because the SEQ_NO exists in SCHEMA2.MYTABLE.
I've got a query which has a WITH statement for a subquery at the top, and I'm then running a couple of CONNECT BYs on the subquery. The subquery can contain tens of thousands of rows, and there's no limit to the depth of the CONNECT BY hierarchy. Currently, this query takes upwards of 30 seconds; is it possible to specify indexes to put on the temporary table created for the factored subquery to speed up the CONNECT BYs, or speed it up another way?
There is no way to do it right in the query: Oracle does not support Eager Spool.
You can temporarily store your resultset in an indexed temporary table and issue the CONNECT BY query against it.
However, for the unsargable equality conditions in the query, the CONNECT BY usually builds a hash table which is in most cases even better than an index.
Could you please post your query here?
You might be able to use the MATERIALIZE hint with query subfactoring so that the subquery isn't being rerun iteratively. While it's undocumented, it seems to reliably flush the results of a WITH clause into a temporary table.
Jonathan Lewis' blog has several examples of how it can be used. There is some risk, however, due to the hint's undocumented nature.