Comments on: FBI Delete

By: Database Scene (@Database_Scene)

Database Scene (@Database_Scene) — Thu, 13 Sep 2012 20:58:17 +0000

Retweeted on DS >> https://twitter.com/Database_Scene
Thank you Jonhathan, for all this awesome work

By: rsiz

rsiz — Thu, 13 Sep 2012 11:47:27 +0000

SQL*Plus: Release 11.2.0.1.0 Production on Thu Sep 13 07:24:02 2012, my unpatched laptop install. And yes, they apparently omit the block access cost for the delete just as in the non-fbi at 229. Without code in hand I can only presume they do some bundling there whichever way you get a list of row ids to delete, but even then the cost with the lousy cluster factor you intentionally created should be much more. I never noticed that before, in my focus on getting the rowid list the cheapest way. Do they perhaps just calculate the lowest cost for getting the rowid list, figuring once you have the rowids the actual cost of the deletes is the same?

By: Jonathan Lewis

Jonathan Lewis — Thu, 13 Sep 2012 08:03:25 +0000

Mark,

Nice idea.

I think the reference to Alex Fatkulin’s blog confirms that the “first k rows” feature (and even the first_rows() hint) is disabled when the optimizer is handling an update or delete – and the arithmetic of the range scan is consistent with that. But your example shows another interesting oddity – its cost ought to be 1,229, because we’ve got a nested loop predicted to access the table by rowid 1,000 times at a cost of 1 per visit – but we don’t multiply the rowid cost by 1,000 (and the join cardinality is only 1 – but that’s another whole problem).

Which version of Oracle are you using ? I see your final predicate references sys_nc00005$ – this happens in my 11.2.0.3, but not in my 10.2.0.3; version can make a difference.

By: Jonathan Lewis

Jonathan Lewis — Thu, 13 Sep 2012 07:48:26 +0000

Mohamed,
Thanks for the link.

By: hourim

hourim — Wed, 12 Sep 2012 07:07:45 +0000

Hi Jonathan,

You said “Whether by accident or design, it looks as if the optimizer hasn’t used the “fkr – first K rows” optimisation change to the delete statement that it applies to the select statement”

In contrast to the select statement, when rownum is present, the first K rows is not used in delete/update statements; see the following blog article for more details

http://afatkulin.blogspot.be/search?q=first_rows

Best regards

By: rsiz

rsiz — Tue, 11 Sep 2012 21:18:22 +0000

Explicity factoring out the rowid selection from the function based index indeed has the same costing error, but presumably since the fbi is smaller than the table in your example even including the rowid, no hint is required to use the fbi. The actual cost is what we would expect. I wonder if the OP's table is so narrow it is smaller or the same number of blocks as his fbi. [sourcecode language="css"] SQL> r 1 delete 2 --+ gather_plan_statistics 3 from t1 where rowid in 4* (select rowid from t1 where (n1+1) <= 100001 and rownum < 1001) 1000 rows deleted. SQL> @q_xplan_allstats_cost SQL> select * from table(dbms_xplan.display_cursor(format=>'COST ALLSTATS LAST')) 2 / PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------------------------------------- SQL_ID 86hh8r8b62qzz, child number 0 ------------------------------------- delete --+ gather_plan_statistics from t1 where rowid in (select rowid from t1 where (n1+1) <= 100001 and rownum < 1001) Plan hash value: 2244916938 | Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| A-Rows | A-Time | Buffers | OMem | 1Mem | Used-Mem | ------------------------------------------------------------------------------------------------------------------------------------------- | 0 | DELETE STATEMENT | | 1 | | 229 (100)| 0 |00:00:00.05 | 8074 | | | | | 1 | DELETE | T1 | 1 | | | 0 |00:00:00.05 | 8074 | | | | | 2 | NESTED LOOPS | | 1 | 1 | 229 (2)| 1000 |00:00:00.01 | 972 | | | | | 3 | VIEW | VW_NSO_1 | 1 | 1000 | 227 (1)| 1000 |00:00:00.01 | 5 | | | | | 4 | SORT UNIQUE | | 1 | 1 | | 1000 |00:00:00.01 | 5 | 73728 | 73728 | | |* 5 | COUNT STOPKEY | | 1 | | | 1000 |00:00:00.01 | 5 | | | | |* 6 | INDEX RANGE SCAN | T1_F1 | 1 | 100K| 227 (1)| 1000 |00:00:00.01 | 5 | | | | | 7 | TABLE ACCESS BY USER ROWID| T1 | 1000 | 1 | 1 (0)| 1000 |00:00:00.01 | 967 | | | | ------------------------------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 5 - filter(ROWNUM<1001) 6 - access("T1"."SYS_NC00005$"<=100001) [/sourcecode]