sql-execution-plan

Extracting data from SQL Server's XML execution plan

你说的曾经没有我的故事 提交于 2019-12-06 07:14:04
问题 My ultimate goal is automatic extraction of all referenced columns from a cached execution plan. This will help us keep a track of all the columns used by our scheduled set of SSRS reports. The XML data of interest looks like this: <ColumnReference Database="[AdventureWorksDW2012]" Schema="[dbo]" Table="[DimCustomer]" Alias="[dC]" Column="HouseOwnerFlag" /> and I would like to store Database, Schema, Table, Alias and Column values in a table. However, for a proof of concept, I have taken a

Postgresql huge performance difference when using IN vs NOT IN

白昼怎懂夜的黑 提交于 2019-12-06 04:52:29
I have 2 tables, "transaksi" and "buku". "transaksi" has around ~250k rows, and buku has around ~170k rows. Both tables have column called "k999a", and both tables use no indexes. Now I check these 2 statements. Statement 1: explain select k999a from transaksi where k999a not in (select k999a from buku); Statement 1 outputs: Seq Scan on transaksi (cost=0.00..721109017.46 rows=125426 width=9) Filter: (NOT (SubPlan 1)) SubPlan 1 -> Materialize (cost=0.00..5321.60 rows=171040 width=8) -> Seq Scan on buku (cost=0.00..3797.40 rows=171040 width=8) Statement 2: explain select k999a from transaksi

How to store query execution plan so that they can be used later

∥☆過路亽.° 提交于 2019-12-06 04:22:15
问题 My applications runs queries against a sql server database. In many cases I can see the benefit of an execution plan: for example I click for the first time on a button to SELECT * from Tasks WHERE IdUser = 24 AND DATE < '12/12/2010' and DATE > '01/01/2010' it takes 15 seconds the first time, 8 seconds the following times. EDIT: I USE PARAMETRIZED QUERIES. So I have a 7 seconds improvement the second time. Now as I run the application again (so I do a new database connection) the first time

MySQL explain filtered column jumping 4,100 with index

半世苍凉 提交于 2019-12-06 01:25:11
问题 My Query: EXPLAIN EXTENDED SELECT `artwork`.`id` , `artwork`.`added` FROM `artwork` ORDER BY `artwork`.`added` DESC LIMIT 0 , 6 When I added an index on "added" to avoid using filesort and use index instead the output of explained went from id select_type table type possible_keys key key_len ref rows filtered Extra 1 SIMPLE artwork ALL NULL NULL NULL NULL 302 100.00 Using filesort to id select_type table type possible_keys key key_len ref rows filtered Extra 1 SIMPLE artwork index NULL added

At what cardinality does SQL Server switch to an index scan (vs. seek)

自闭症网瘾萝莉.ら 提交于 2019-12-06 01:00:59
问题 Assuming that a table contains sufficient information to warrant an index seek, at what cardinality will SQL Server (or PostgreSQL) opt for an index scan? The reason I ask this is I previously posted a question (link) in which two queries performed at the same speed, yet one didn't attempt to use the index on the processed columns. After SQL Server suggested I put a covering index that included the columns being queried (it suggested this for both queries), I started looking for reasons as to

Stored procedure SQL execution plan

瘦欲@ 提交于 2019-12-05 17:27:46
I'm a bit stuck with a stored procedure that is executing really slow. The stored procedure basically contains a query that uses an incoming parameter (in_id) and is put in a cursor like this: open tmp_cursor for select col1, col2, col3 from table1 tab where ((in_id is null) or (tab.id = in_id)); -- tab.id is the PK When I get an execution plan for the SQL query separately with predefined value, I get good results with the query using an index. However when I call the procedure from my application, I see that no index is being used and the table gets full scan, thus giving slow performance. If

Why are the performances of these 2 queries so different?

橙三吉。 提交于 2019-12-05 16:43:21
问题 I have a stored proc that searches for products (250,000 rows) using a full text index. The stored proc takes a parameter that is the full text search condition. This parameter can be null, so I added a null check and the query suddenly started running orders of magnitude slower. -- This is normally a parameter of my stored proc DECLARE @Filter VARCHAR(100) SET @Filter = 'FORMSOF(INFLECTIONAL, robe)' -- #1 - Runs < 1 sec SELECT TOP 100 ID FROM dbo.Products WHERE CONTAINS(Name, @Filter) -- #2

How reliable is the cost measurement in PostgreSQL Explain Plan?

狂风中的少年 提交于 2019-12-05 11:32:44
The queries are performed on a large table with 11 million rows. I have already performed an ANALYZE on the table prior to the query executions. Query 1: SELECT * FROM accounts t1 LEFT OUTER JOIN accounts t2 ON (t1.account_no = t2.account_no AND t1.effective_date < t2.effective_date) WHERE t2.account_no IS NULL; Explain Analyze: Hash Anti Join (cost=480795.57..1201111.40 rows=7369854 width=292) (actual time=29619.499..115662.111 rows=1977871 loops=1) Hash Cond: ((t1.account_no)::text = (t2.account_no)::text) Join Filter: ((t1.effective_date)::text < (t2.effective_date)::text) -> Seq Scan on

how to generate explain plan for entire stored procedure

守給你的承諾、 提交于 2019-12-05 07:59:29
I usually generate explain plans using the following in sqlplus: SET AUTOTRACE ON SET TIMING ON SET TRIMSPOOL ON SET LINES 200 SPOOL filename.txt SET AUTOTRACE TRACEONLY; {query goes here} SPOOL OFF SET AUTOTRACE OFF But what If I want to generate explain plan for a stored procedure? Is there a way to generate explain plan for the entire stored procedure? The SP has no input/output parameters. What you are generating is correctly called an "execution plan". "Explain plan" is a command used to generate and view an execution plan, much as AUTOTRACE TRACEONLY does in your example. By definition,

SQL Server sp_ExecuteSQL and Execution Plans

梦想与她 提交于 2019-12-05 06:34:26
I have a query which is superfast in SQL Server Management STudio and super slow when run under sp_ExecuteSQL. Is this to do with caching of execution plans not happening when run under spExecuteSQL? No. You can see both execution plans and compare them using the following query. SELECT usecounts, cacheobjtype, objtype, text, query_plan, value as set_options FROM sys.dm_exec_cached_plans CROSS APPLY sys.dm_exec_sql_text(plan_handle) CROSS APPLY sys.dm_exec_query_plan(plan_handle) cross APPLY sys.dm_exec_plan_attributes(plan_handle) AS epa where text like '%Some unique string in your query%'