confusion about cardinality in explain plan node on compressed table

[db2admin]

hello,

I have compressed table 442992 rows and when i run explain plan on
this table for some SQL using this table, i see table scan and
cardinality on top of table node as 18458. I am new to compression and
do not understand why cardinality is not the actual number of rows but
18458.
look below at table ABC.XYZ

672
BTQ
( 30)
122.764
99
|
28
TBSCAN
( 31)
122.507
99
|
18458
TABLE: ABC
XYZ

[Ian]

db2admin wrote:

hello,

I have compressed table 442992 rows and when i run explain plan on
this table for some SQL using this table, i see table scan and
cardinality on top of table node as 18458. I am new to compression and
do not understand why cardinality is not the actual number of rows but
18458.
look below at table ABC.XYZ

672
BTQ
( 30)
122.764
99
|
28
TBSCAN
( 31)
122.507
99
|
18458
TABLE: ABC
XYZ

This has nothing to do with compression. You are running with DPF, and
ABC.XYZ has 24 partitions.

The TBSCAN (31) happens on each data partition -- each data partition
should have approximately 1/24 of the data.

[db2admin]

On Oct 21, 1:18*pm, Ian <[e-mail]:

db2admin wrote:

hello,

I have compressed table 442992 rows and when i run explain plan on
this table for some SQL using this table, i see table scan and
cardinality on top of table node as 18458. I am new to compression and
do not understand why cardinality is not the actual number of rows but
18458.
look below at table ABC.XYZ

* * * 672
* * BTQ
* * ( *30)
* * 122.764
* * * 99
* * * |
* * * 28
* * TBSCAN
* * ( *31)
* * 122.507
* * * 99
* * * |
* * *18458
TABLE: ABC
* *XYZ

This has nothing to do with compression. *You are running with DPF, and
ABC.XYZ has 24 partitions.

The TBSCAN (31) happens on each data partition -- each data partition
should have approximately 1/24 of the data.

yes
thankyou
how did i miss that one