A question about explain plan

Question

here is my sql statement and running result:
SQL> @bind_variables_peeking_test.sql
SQL> SET ECHO OFF
SQL>
SQL> REM
SQL> REM Setup test environment
SQL> REM
SQL>
SQL> ALTER SYSTEM FLUSH SHARED_POOL;
SQL>
SQL> DROP TABLE t;
DROP TABLE t
ERROR at line 1:
ORA-00942: table or view does not exist
SQL>
SQL> CREATE TABLE t
2 AS
3 SELECT rownum AS id
4 FROM dual
5 CONNECT BY level <= 1000;
SQL>
SQL> execute dbms_stats.gather_table_stats(ownname=>user, tabname=>'t');
SQL> SELECT count(id), count(DISTINCT id), min(id), max(id) FROM t;
COUNT(ID) COUNT(DISTINCTID) MIN(ID) MAX(ID)
1000 1000 1 1000
SQL>
SQL> PAUSE
SQL>
SQL> REM
SQL> REM Without bind variables different execution plans are used if the value
SQL> REM used in the WHERE clause change. This is because the query optimizer
SQL> REM recognize the different selectivity of the two predicates.
SQL> REM
SQL>
SQL> SELECT count(*) FROM t WHERE id < 990;
COUNT(*)
989
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID bspfffaycy92u, child number 0
SELECT count(*) FROM t WHERE id < 990
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 990 | 2970 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<990)
SQL>
SQL> PAUSE
SQL>
SQL> SELECT count(*) FROM t WHERE id < 10;
COUNT(*)
9
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID 4xfxt0frkj40y, child number 0
SELECT count(*) FROM t WHERE id < 10
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 9 | 27 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<10)
SQL>
SQL> PAUSE
SQL>
SQL> REM
SQL> REM With bind variables the same execution plan is used. Depending on the
SQL> REM peeked value (10 or 990), a full table scan or an index range scan is used.
SQL> REM
SQL>
SQL> EXECUTE :id := 10;
SQL>
SQL> SELECT count(*) FROM t WHERE id < :id;
COUNT(*)
9
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID dkva59ypaxa6w, child number 0
SELECT count(*) FROM t WHERE id < :id
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 9 | 27 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<:ID)
SQL>
SQL> PAUSE
SQL>
SQL> EXECUTE :id := 10;
SQL>
SQL> SELECT count(*) FROM t WHERE id < :id;
COUNT(*)
9
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID dkva59ypaxa6w, child number 0
SELECT count(*) FROM t WHERE id < :id
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 9 | 27 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<:ID)
SQL>
SQL> PAUSE
SQL>
SQL> ALTER SYSTEM FLUSH SHARED_POOL;
SQL>
SQL> PAUSE
SQL>
SQL> EXECUTE :id := 10;
SQL> SELECT count(*) FROM t WHERE id < :id;
COUNT(*)
9
SQL> explain plan for SELECT count(*) FROM t WHERE id < :id;
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 3 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 50 | 150 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<TO_NUMBER(:ID))
SQL>
SQL> ALTER SYSTEM FLUSH SHARED_POOL;
SQL> PAUSE
SQL>
SQL> EXECUTE :id := 10;
SQL>
SQL> SELECT count(*) FROM t WHERE id < :id;
COUNT(*)
9
SQL>
SQL> SELECT * FROM table(dbms_xplan.display_cursor(NULL, NULL, 'typical'));
PLAN_TABLE_OUTPUT
SQL_ID dkva59ypaxa6w, child number 0
SELECT count(*) FROM t WHERE id < :id
Plan hash value: 2966233522
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 3 (100)| |
| 1 | SORT AGGREGATE | | 1 | 3 | | |
|* 2 | TABLE ACCESS FULL| T | 9 | 27 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("ID"<:ID)
SQL>
SQL>
SQL> PAUSE
SQL>
SQL> REM
SQL> REM Cleanup
SQL> REM
SQL>
SQL> UNDEFINE sql_id
SQL>
SQL> DROP TABLE t;
SQL> PURGE TABLE t;
SQL>
SQL> spool off;
please noticed the last two explain plan result,one sql statement but have two result,why?

Answer 1

what do you mean "invalidated the previous plan"?
i gather the table statistics information once.
every time before i run the statement and explain plan, i flush share pool to make sure there are not execution plan to reused.
so i think i do not invalidated the previous plan and the two result should be same.