The way in which Oracle accesses data is aptly called an access method. The result shows you the estimated number of rows ( E-Rows) and the actual number of rows ( A-Rows), which can of course be quite different because of data skew.ĭon’t use this hint in a production environment as each query incurs some overhead. Interestingly, you can see runtime cardinality information by using the GATHER_PLAN_STATISTICS hint in your query, after which you have to execute SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR(FORMAT=>'ALLSTATS LAST')). What can (negatively) impact the accuracy of the estimate and therefore the quality of the execution plan are i) data skew, ii) multiple single-column predicates on a single table, iii) function-wrapped columns in WHERE clause predicates, and iv) complex expressions. The number of rounded up and shown in the column CARDINALITY. The query optimizer will then assume a uniform distribution, so that the cardinality of each operation in the execution plan is calculated by dividing the total number of rows by the number of distinct values after the equality predicate has been applied. If not, Oracle has to estimate the cardinality.įor instance, suppose you have an equality predicate in a single-table query, for which there is no histogram (i.e. The cardinality is computed from table and column statistics, if available.
In the context of execution plans, the cardinality shows the number of rows estimated to come out of each operation.
It is a measure of the number of distinct elements in a column.Ī low cardinality implies that a column has very few distinct values, and is thus not very selective. What cardinality refers to is the uniqueness (or lack thereof) of data in a particular column of a database table. No, cardinality has nothing to do with the clergy.
0 kommentar(er)
