Curious case with optimiser explain

Database
N/A

Curious case with optimiser explain

select   a.column1

            a.column2

            a.column3

            ....

            a.column20

from     table a

Table a is a big table , with count (*) around 800 million. 

Explain for above query is working fine . It return as

 The size of Spool 1 is estimated with high confidence to be

     800,455,275 rows (430,640,556,075 bytes).  The estimated time for

     this step is 8 minutes and 59 seconds.

So far so good. Now when I'm adding anothe table in sub query , things are getting curious.

select    a.column1

            a.column2

            a.column3

            ....

            a.column20

from     table a

where  1= (select switch from table b);

a

Table a is a big table , with count (*) around 800 million ( same from 1st query). Table b is a single row table with either 0 or 1 as value, based on load switch. At time of running the query , the value is 1.

Here's the explain for the query. Step 6 is showing low confidence with just 10% of actual row count of table a where as the WHERE condition is true and should pick all rows from table a. Stats are up to date. Any idea behind the logic used by explain plan ?

 This request is eligible for incremental planning and execution (IPE).

 The following is the static plan for the request.

  1) First, we lock a distinct a for read on

     a RowHash to prevent global deadlock for a.

  2) Next, we lock a distinct b for read on a

     RowHash to prevent global deadlock for b.

  3) We lock a for read, and we lock  b for read.

  4) We do an all-AMPs RETRIEVE step from b by

     way of an all-rows scan with no residual conditions into Spool 1

     (all_amps), which is built locally on the AMPs.  The size of Spool

     1 is estimated with high confidence to be 1 row (23 bytes).  The

     estimated time for this step is 0.01 seconds.

  5) We do an all-AMPs DISPATCHER RETRIEVE step from Spool 1 (Last Use)

     by way of an all-rows scan and send the rows back to the

     Dispatcher.  The size is estimated with high confidence to be 1

     row.  The estimated time for this step is 0.00 seconds.

  6) We do an all-AMPs RETRIEVE step from a by way

     of an all-rows scan with a condition of ("1 = :%SSQ20") into Spool

     2 (group_amps), which is built locally on the AMPs.  The input

     table will not be cached in memory, but it is eligible for

     synchronized scanning.  The result spool file will not be cached

     in memory.  The size of Spool 2 is estimated with no confidence to

     be 84,139,388 rows (43,163,506,044 bytes).  The estimated time for

     this step is 2 minutes and 42 seconds.