# Verifying Statistics Using `EXPLAIN` Command - Cont'd

+ Index is still used, although 20,000 records with identical `pname` are inserted.
+ `states:pseudo` means the statistics is inaccurate.

```
tidb> SELECT COUNT(*) FROM T2;
+----------+
| count(*) |
+----------+
|  20000   |
+----------+
1 row in set (0.01 sec)

tidb> SELECT * FROM T2 LIMIT 10;
+----+-------+-------+------+
| id | pname | price | info |
+----+-------+-------+------+
| 1  |  000  | 9999  | none |
| 2  |  000  | 9999  | none |
...
| 9  |  000  | 9999  | none |
| 10 |  000  | 9999  | none |
+----+-------+-------+------+
10 rows in set (0.00 sec)

tidb> EXPLAIN SELECT * FROM T2 WHERE pname='000';
+---------------------------+---------+-----------+----------------------------------+-----------------------------------------------------+
| id                        | estRows | task      | access object                    | operator info                                       |
+---------------------------+---------+-----------+----------------------------------+-----------------------------------------------------+
| IndexLookUp_10            |  20.00  | root      |                                  |                                                     |
| ├─IndexRangeScan_8(Build) |  20.00  | cop[tikv] | table:T2, index:idx_pname(pname) | range:["000","000"], keep order:false, ~!@stats:pseudo@!~ |
| └─TableRowIDScan_9(Probe) |  20.00  | cop[tikv] | table:T2                         | keep order:false, ~!@stats:pseudo@!~                      |
+---------------------------+---------+-----------+----------------------------------+-----------------------------------------------------+
3 rows in set (0.00 sec)
```
------------------------------------------------------------------------------
Next, we insert 20,000 rows of data and perform another query.

Even after the insertion of 20,000 rows, the execution plan for table T2 continues to utilize the index `idx_pname`. You might argue: This approach seems flawed! Given that the `pname` column has no distinct values (resulting in low cardinality), following the current execution plan that involves an index scan (`IndexRangeScan`) followed by a table lookup may fail to effectively leverage the I/O bandwidth. In the worst-case scenario, this plan could read row by row, leading to I/O operations approaching the total number of rows in the table. Consequently, this would offer poorer performance than a full table scan, which can efficiently utilize I/O bandwidth to read and process data in batches. Clearly, the optimizer's execution plan is not optimal.

Indeed, in this specific case, the optimizer's chosen execution plan is suboptimal. However, it is important to understand that the optimizer currently lacks awareness that every row in the `pname` column is identical.

In the operator info section, we observe a marker labeled `stats:pseudo`. This serves as a warning from the optimizer, indicating that the statistics for this table are outdated, and as a result, the generated physical execution plan may not be optimal. The question arises: How does the optimizer discern that the statistics are outdated?