I'm using TD v6.01 V2R.
In fact, logically, I agree with you!
This is the EXPLAIN of the whole query when I put 1=0 (I hide real object names):
1) First, we do a single-AMP RETRIEVE step from
DB.MYTABLE by way of the unique primary
index with unsatisfiable conditions derived by SAT. The estimated
time for this step is 0.01 seconds.
-> The row is sent directly back to the user as the result of
statement 1. The total estimated time is 0.01 seconds.
Which is pretty immediate and it explains why it runs in less than one sec.
This is an extract of the very long EXPLAIN when I put (
CURRENT_DATE
-
DATE
'0001-01-01'
) MOD 7 = 0:
7) We execute the following steps in parallel.
1) We do an all-AMPs RETRIEVE step from
DB.MYTABLE by way of an all-rows
scan with a condition of ("((((DATE )- (DATE '0001-01-01'))
MOD 7 )= 0) AND
((DB.MYTABLE.C1 = (((DATE
)- (DATE '0001-01-01')) MOD 7 )) AND
((DB.MYTABLE.C2
= (((DATE )- (DATE '0001-01-01')) MOD 7 )) AND
((DB.MYTABLE.C3 =
(((DATE )- (DATE '0001-01-01')) MOD 7 )) AND
((DB.MYTABLE.C4
= (((DATE )- (DATE '0001-01-01')) MOD 7 )) AND
((DB.MYTABLE.C5 =
(((DATE )- (DATE '0001-01-01')) MOD 7 )) AND
((DB.MYTABLE.C6 =
(((DATE )- (DATE '0001-01-01')) MOD 7 )) AND
((DB.MYTABLE.C7 =
(((DATE )- (DATE '0001-01-01')) MOD 7 )) AND
((DB.MYTABLE.C8 = (((DATE )-
(DATE '0001-01-01')) MOD 7 )) AND
((DB.MYTABLE.C9= (((DATE )-
(DATE '0001-01-01')) MOD 7 )) AND
((DB.MYTABLE.C10 >= ((((DATE )-
(DATE '0001-01-01')) MOD 7 )+ 18 )) AND
((DB.MYTABLE.C10 <= ((((DATE )-
(DATE '0001-01-01')) MOD 7 )+ 64 )) AND
((DB.MYTABLE.C11 = ((((DATE
)- (DATE '0001-01-01')) MOD 7 )+ 1 )) AND
((DB.MYTABLE.C12 = ((((DATE
)- (DATE '0001-01-01')) MOD 7 )+ 1 )) AND
((DB.MYTABLE.C13 = ((((DATE
)- (DATE '0001-01-01')) MOD 7 )+ 1 )) AND
((DB.MYTABLE.C1 = 0) AND
((DB.MYTABLE.C2
= 0) AND
((DB.MYTABLE.C3 = 0)
AND
((DB.MYTABLE.C4
= 0) AND
((DB.MYTABLE.C5 = 0)
AND ((DB.MYTABLE.C6 = 0)
AND ((DB.MYTABLE.C7 = 0)
AND ((DB.MYTABLE.C8 = 0) AND
((DB.MYTABLE.C9 = 0) AND
((DB.MYTABLE.C10 <= 64) AND
((DB.MYTABLE.C10 >= 18) AND
((DB.MYTABLE.C11 = 1) AND
((DB.MYTABLE.C12= 1) AND
((DB.MYTABLE.C13 = 1) AND
(DB.MYTABLE.C14 =
'INDIVIDUALS')))))))))))))))))))))))))))))") into Spool 5
(all_amps), which is redistributed by hash code to all AMPs.
Then we do a SORT to order Spool 5 by row hash. The input
table will not be cached in memory, but it is eligible for
synchronized scanning. The size of Spool 5 is estimated with
no confidence to be 380 rows. The estimated time for this
step is 52.38 seconds.
2) We do an all-AMPs RETRIEVE step from
DB.MYTABLE2 by way of an all-rows
scan with a condition of (
<some other irrelevant conditions)
into Spool 6 (all_amps), which is
redistributed by hash code to all AMPs. Then we do a SORT to
order Spool 6 by row hash and the sort key in spool field1
eliminating duplicate rows. The input table will not be
cached in memory, but it is eligible for synchronized
scanning. The size of Spool 6 is estimated with no
confidence to be 3,310,704 rows. The estimated time for this
step is 34.45 seconds.
8) We do an all-AMPs JOIN step from Spool 5 (Last Use) by way of an
all-rows scan, which is joined to Spool 6 (Last Use) by way of an
all-rows scan. Spool 5 and Spool 6 are joined using an exclusion
merge join, with a join condition of (<a join condition>).
The result goes into Spool 7 (all_amps), which is built locally on
the AMPs. The size of Spool 7 is estimated with no confidence to
be 380 rows. The estimated time for this step is 0.03 seconds.
I've replaced object names with fake names but I've preserved the structure.
Why is it computing the whole query?
Thanks again
I'm using TD v6.01 V2R.
In fact, logically, I agree with you!
This is the EXPLAIN of the whole query when I put 1=0 (I hide real object names):
Which is pretty immediate and it explains why it runs in less than one sec.
This is an extract of the very long EXPLAIN when I put
(
CURRENT_DATE
-
DATE
'0001-01-01'
) MOD 7 = 0:
I've replaced object names with fake names but I've preserved the structure.
Why is it computing the whole query?
Thanks again