sql-execution-plan

Now I have a really tricky thing with Oracle execution plans running havoc, when I use a DETERMINISTIC function on the right hand side of the LIKE operator. This is my situation: The Situation I thought it to be wise to execute a query like this (simplified): SELECT [...] FROM customers cust JOIN addresses addr ON addr.cust_id = cust.id WHERE special_char_filter(cust.surname) like special_char_filter(?) And I would bind ? to something like 'Eder%' . Now customers and addresses are very large tables. That's why it's important to use indexes. Of course, there is a regular index on addresses.cust

I know I can change the way MySQL executes a query by using the FORCE INDEX (abc) keyword. But is there a way to change the execution order? My query looks like this: SELECT c.* FROM table1 a INNER JOIN table2 b ON a.id = b.table1_id INNER JOIN table3 c ON b.itemid = c.itemid WHERE a.itemtype = 1 AND a.busy = 1 AND b.something = 0 AND b.acolumn = 2 AND c.itemid = 123456 I have a key for every relation/constraint that I use. If I run explain on this statement I see that mysql starts querying c first. id select_type table type 1 SIMPLE c ref 2 SIMPLE b ref 3 SIMPLE a eq_ref However, I know that

Does anyone have a query which searches through SQL2005/2008's plan cache identifying queries or stored procedures which have table/index scans within their execution plans? Pinal Dave actually did a post about this and with a bit of alteration on his original article (barely any alteration required!) you can get the right answer. If he's got an account, credit him :) http://blog.sqlauthority.com/2009/03/17/sql-server-practical-sql-server-xml-part-one-query-plan-cache-and-cost-of-operations-in-the-cache/ His Query is: WITH XMLNAMESPACES(DEFAULT N'http://schemas.microsoft.com/sqlserver/2004/07

I have two huge tables: Table "public.tx_input1_new" (100,000,000 rows) Column | Type | Modifiers ----------------|-----------------------------|---------- blk_hash | character varying(500) | blk_time | timestamp without time zone | tx_hash | character varying(500) | input_tx_hash | character varying(100) | input_tx_index | smallint | input_addr | character varying(500) | input_val | numeric | Indexes: "tx_input1_new_h" btree (input_tx_hash, input_tx_index) Table "public.tx_output1_new" (100,000,000 rows) Column | Type | Modifiers --------------+------------------------+----------- tx_hash |

We are running Postgres 9.3.5. (07/2014) We have quite some complex datawarehouse/reporting setup in place (ETL, materialized views, indexing, aggregations, analytical functions, ...). What I discovered right now may be difficult to implement in the optimizer (?), but it makes a huge difference in performance (only sample code with huge similarity to our query to reduce unnecessary complexity): create view foo as select sum(s.plan) over w_pyl as pyl_plan, -- money planned to spend in this pot/loc/year sum(s.booked) over w_pyl as pyl_booked, -- money already booked in this pot/loc/year -- money

Can anyone explain me what is the difference between execution plan and explain plan. When I execute set autotrace traceonly; select * from emp where empno=7369; Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=1 Card=1 Bytes=38) 1 0 TABLE ACCESS BY INDEX ROWID SCOTT.EMP (Cost=1 Card=1 Bytes=38) 2 1 INDEX UNIQUE SCAN SCOTT.PK_EMP (Cost=0 Card=1) Explain Plan explain plan for select * from emp where empno=7369; select * from table(dbms_xplan.display); Plan hash value: 2949544139 -------------------------------------------