[Info-ingres] Strange change in QEP of unioned subselects

#1

Ingres 2.6 on SunOS

There is a SELECT statement of type
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT...

Each subselect references several tables.The list is the same for each
subselect.
The qep is correct. The execution of each subselect begins from a secondary
index on table U.

Now add 'create table tmp_000 as..' at the beginning of this statement
and the qep changes to bad: no use of the index, the execution starts from
Proj-rest node on table U.

I suspect we reach some internal limit of the number of tables referenced in
qep. Is there any other explanation ?.
Note that the qep remains ok if we add 'create table as ..', but reduce the
number of subselects to 3.

Piotr

#2

<Piotr.Wisniewski (AT) breat (DOT) com.pl> wrote

Quote:

Ingres 2.6 on SunOS

There is a SELECT statement of type
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT...

Each subselect references several tables.The list is the same for each
subselect.
The qep is correct. The execution of each subselect begins from a
secondary
index on table U.

Now add 'create table tmp_000 as..' at the beginning of this statement
and the qep changes to bad: no use of the index, the execution starts from
Proj-rest node on table U.

Is that bad? The use of an index is not automatically a good thing. Quite
often it is a (very) bad thing. What happens to the response time? Can we
see the two different sets of QEPs?

Quote:

I suspect we reach some internal limit of the number of tables referenced
in
qep. Is there any other explanation ?.

There is a limit on the number of range variables in a query (30 in your
version), but if you exceed it the query just fails. Adding more tables to
the query can perturb the order in which candidate query plans are
generated, so if the OPF times out you can end up with a different plan.
Did it time out?

Quote:

Note that the qep remains ok if we add 'create table as ..', but reduce
the
number of subselects to 3.

See above.

Roy Hann (rhann at rationalcommerc dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

#3

The limit of 30 range variables that Roy describes below is for all
relations: base tables, secondary indices and temporary tables (e.g. for
unflattened subselects). As you increase the number of union partitions,
and therefore increase the number of base relations that have to be
included in the 30 range variables, the number of range variable slots
available for secondary indices decreases.

You can use trace point op156 (and search for 'GLOBAL VAR' in the
output) to see which relations are being chosen.

-----Original Message-----
From: info-ingres-admin (AT) cariboulake (DOT) com
[mailto:info-ingres-admin (AT) cariboulake (DOT) com] On Behalf Of Roy Hann
Sent: 21 March 2005 12:52
To: info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] Strange change in QEP of unioned subselects

<Piotr.Wisniewski (AT) breat (DOT) com.pl> wrote

Quote:

Ingres 2.6 on SunOS

There is a SELECT statement of type
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT...

Each subselect references several tables.The list is the same for each
subselect.
The qep is correct. The execution of each subselect begins from a
secondary
index on table U.

Now add 'create table tmp_000 as..' at the beginning of this statement
and the qep changes to bad: no use of the index, the execution starts
from
Proj-rest node on table U.

Is that bad? The use of an index is not automatically a good thing.
Quite
often it is a (very) bad thing. What happens to the response time?
Can we
see the two different sets of QEPs?

Quote:

I suspect we reach some internal limit of the number of tables
referenced

in

Quote:

qep. Is there any other explanation ?.

There is a limit on the number of range variables in a query (30 in your
version), but if you exceed it the query just fails. Adding more tables
to
the query can perturb the order in which candidate query plans are
generated, so if the OPF times out you can end up with a different plan.
Did it time out?

Quote:

Note that the qep remains ok if we add 'create table as ..', but
reduce

the

Quote:

number of subselects to 3.

See above.

Roy Hann (rhann at rationalcommerc dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

#4

Adding set joinop notimeout at the beginning doesn't help.
I need the qep with the use of secondary index as it greatly reduces
execution time.

What is going on here ?
Why adding 'create table as...' at the beginning changes the qep to bad ?

-----Original Message-----
From: Roy Hann [mailto:specially (AT) processed (DOT) almost.meat]
Sent: Monday, March 21, 2005 1:52 PM
To: info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] Strange change in QEP of unioned subselects

<Piotr.Wisniewski (AT) breat (DOT) com.pl> wrote

Quote:

Ingres 2.6 on SunOS

There is a SELECT statement of type
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT...

Each subselect references several tables.The list is the same for each
subselect.
The qep is correct. The execution of each subselect begins from a
secondary
index on table U.

Now add 'create table tmp_000 as..' at the beginning of this statement
and the qep changes to bad: no use of the index, the execution starts from
Proj-rest node on table U.

Is that bad? The use of an index is not automatically a good thing. Quite
often it is a (very) bad thing. What happens to the response time? Can we
see the two different sets of QEPs?

Quote:

I suspect we reach some internal limit of the number of tables referenced
in
qep. Is there any other explanation ?.

There is a limit on the number of range variables in a query (30 in your
version), but if you exceed it the query just fails. Adding more tables to
the query can perturb the order in which candidate query plans are
generated, so if the OPF times out you can end up with a different plan.
Did it time out?

Quote:

Note that the qep remains ok if we add 'create table as ..', but reduce
the
number of subselects to 3.

See above.

Roy Hann (rhann at rationalcommerc dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

#5

<Piotr.Wisniewski (AT) breat (DOT) com.pl> wrote

Quote:

Adding set joinop notimeout at the beginning d oesn'thelp.

OK.

Quote:

I need the qep with the use of secondary index as it greatly reduces
execution time.

THAT is what I needed to hear.

Quote:

What is going on here ?
Why adding 'create table as...' at the beginning changes the qep to bad ?

Well (of course) it never should. Obviously the optimizer is mistaken, and
we've ruled out timeout as the source of that mistake. There are two fairly
likely explanations remaining: poor cost estimates (likely due to
missing/stale/wrong statistics), and bugs. Let's concentrate on stats for
the moment. Have you tried running the two versions of the query with trace
point QE90 set?

You might also want to try setting trace point OP188 to see if your
preferred plan shows up when you optimize the CREATE TABLE version, and to
see how it compares with the one that got selected instead.

Does your CREATE TABLE statement include a WITH STRUCTURE clause? Does it
include WITH NOJOURNALING?

Can we see the SQL, table help, and plans?

Roy

#6

I did that plus some greping and I see my index falls out when there is
'create table .. as ' (VAR=31 name: idx_t161_02) below.
Why there is the hole between number 28 and 30/31 ?

Version without 'create table':
GLOBAL VAR=24, RDR_INFO: DMT_TBL_ENTRY: table name= fund_price_unit_hist_03
GLOBAL VAR=25, RDR_INFO: DMT_TBL_ENTRY: table name= instruction_type_dir_02
GLOBAL VAR=26, RDR_INFO: DMT_TBL_ENTRY: table name= inv_instr_commission_07
GLOBAL VAR=27, RDR_INFO: DMT_TBL_ENTRY: table name= sale_instr_054, id-base
GLOBAL VAR=28, RDR_INFO: DMT_TBL_ENTRY: table name= batch_register_051, id-
GLOBAL VAR=30, RDR_INFO: DMT_TBL_ENTRY: table name= idx_t161_01, id-base=14
GLOBAL VAR=31, RDR_INFO: DMT_TBL_ENTRY: table name= idx_t161_02, id-base=14
OPV_GLOBAL_RANGE: base=525006848, num=32

Version with 'create table':
GLOBAL VAR=22, RDR_INFO: DMT_TBL_ENTRY: table name= investor_unit_acct_021,
GLOBAL VAR=23, RDR_INFO: DMT_TBL_ENTRY: table name= investor_accounts_019,
GLOBAL VAR=24, RDR_INFO: DMT_TBL_ENTRY: table name= fund_price_unit_hist_03
GLOBAL VAR=25, RDR_INFO: DMT_TBL_ENTRY: table name= instruction_type_dir_02
GLOBAL VAR=26, RDR_INFO: DMT_TBL_ENTRY: table name= inv_instr_commission_07
GLOBAL VAR=27, RDR_INFO: DMT_TBL_ENTRY: table name= sale_instr_054, id-base
GLOBAL VAR=28, RDR_INFO: DMT_TBL_ENTRY: table name= batch_register_051, id-
GLOBAL VAR=31, RDR_INFO: DMT_TBL_ENTRY: table name= idx_t161_01, id-base=14
OPV_GLOBAL_RANGE: base=525006848, num=32

-----Original Message-----
From: Hayden, Keith C [mailto:Keith.Hayden (AT) ca (DOT) com]
Sent: Monday, March 21, 2005 2:41 PM
To: info-ingres (AT) cariboulake (DOT) com
Subject: RE: [Info-ingres] Strange change in QEP of unioned subselects

The limit of 30 range variables that Roy describes below is for all
relations: base tables, secondary indices and temporary tables (e.g. for
unflattened subselects). As you increase the number of union partitions,
and therefore increase the number of base relations that have to be
included in the 30 range variables, the number of range variable slots
available for secondary indices decreases.

You can use trace point op156 (and search for 'GLOBAL VAR' in the
output) to see which relations are being chosen.

-----Original Message-----
From: info-ingres-admin (AT) cariboulake (DOT) com
[mailto:info-ingres-admin (AT) cariboulake (DOT) com] On Behalf Of Roy Hann
Sent: 21 March 2005 12:52
To: info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] Strange change in QEP of unioned subselects

<Piotr.Wisniewski (AT) breat (DOT) com.pl> wrote

Quote:

Ingres 2.6 on SunOS

There is a SELECT statement of type
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT...

Each subselect references several tables.The list is the same for each
subselect.
The qep is correct. The execution of each subselect begins from a
secondary
index on table U.

Now add 'create table tmp_000 as..' at the beginning of this statement
and the qep changes to bad: no use of the index, the execution starts
from
Proj-rest node on table U.

Is that bad? The use of an index is not automatically a good thing.
Quite
often it is a (very) bad thing. What happens to the response time?
Can we
see the two different sets of QEPs?

Quote:

I suspect we reach some internal limit of the number of tables
referenced

in

Quote:

qep. Is there any other explanation ?.

There is a limit on the number of range variables in a query (30 in your
version), but if you exceed it the query just fails. Adding more tables
to
the query can perturb the order in which candidate query plans are
generated, so if the OPF times out you can end up with a different plan.
Did it time out?

Quote:

Note that the qep remains ok if we add 'create table as ..', but
reduce

the

Quote:

number of subselects to 3.

See above.

Roy Hann (rhann at rationalcommerc dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

#7

Hi Piotr,

Try searching for 'grv:' (grv = global range variable) in the op156
output and you may see the entries for 29 and 30. These may be temporary
relations used in the creation of the temp table.

As you have seen, the number of range variables allowed is 32 (0 -> 31)
rather than 30 - 30 is the parser's limit for user defined base
relations, whereas the query optimizer allows 32 base relations, temp
relations and secondary indices.

Thanks,
Keith.

-----Original Message-----
From: Piotr.Wisniewski (AT) breat (DOT) com.pl
[mailto:Piotr.Wisniewski (AT) breat (DOT) com.pl]
Sent: 21 March 2005 14:44
To: Hayden, Keith C; info-ingres (AT) cariboulake (DOT) com
Subject: RE: [Info-ingres] Strange change in QEP of unioned subselects

I did that plus some greping and I see my index falls out when there is
'create table .. as ' (VAR=31 name: idx_t161_02) below.
Why there is the hole between number 28 and 30/31 ?

Version without 'create table':
GLOBAL VAR=24, RDR_INFO: DMT_TBL_ENTRY: table name=
fund_price_unit_hist_03
GLOBAL VAR=25, RDR_INFO: DMT_TBL_ENTRY: table name=
instruction_type_dir_02
GLOBAL VAR=26, RDR_INFO: DMT_TBL_ENTRY: table name=
inv_instr_commission_07
GLOBAL VAR=27, RDR_INFO: DMT_TBL_ENTRY: table name= sale_instr_054,
id-base
GLOBAL VAR=28, RDR_INFO: DMT_TBL_ENTRY: table name= batch_register_051,
id-
GLOBAL VAR=30, RDR_INFO: DMT_TBL_ENTRY: table name= idx_t161_01,
id-base=14
GLOBAL VAR=31, RDR_INFO: DMT_TBL_ENTRY: table name= idx_t161_02,
id-base=14
OPV_GLOBAL_RANGE: base=525006848, num=32

Version with 'create table':
GLOBAL VAR=22, RDR_INFO: DMT_TBL_ENTRY: table name=
investor_unit_acct_021,
GLOBAL VAR=23, RDR_INFO: DMT_TBL_ENTRY: table name=
investor_accounts_019,
GLOBAL VAR=24, RDR_INFO: DMT_TBL_ENTRY: table name=
fund_price_unit_hist_03
GLOBAL VAR=25, RDR_INFO: DMT_TBL_ENTRY: table name=
instruction_type_dir_02
GLOBAL VAR=26, RDR_INFO: DMT_TBL_ENTRY: table name=
inv_instr_commission_07
GLOBAL VAR=27, RDR_INFO: DMT_TBL_ENTRY: table name= sale_instr_054,
id-base
GLOBAL VAR=28, RDR_INFO: DMT_TBL_ENTRY: table name= batch_register_051,
id-
GLOBAL VAR=31, RDR_INFO: DMT_TBL_ENTRY: table name= idx_t161_01,
id-base=14
OPV_GLOBAL_RANGE: base=525006848, num=32

-----Original Message-----
From: Hayden, Keith C [mailto:Keith.Hayden (AT) ca (DOT) com]
Sent: Monday, March 21, 2005 2:41 PM
To: info-ingres (AT) cariboulake (DOT) com
Subject: RE: [Info-ingres] Strange change in QEP of unioned subselects

The limit of 30 range variables that Roy describes below is for all
relations: base tables, secondary indices and temporary tables (e.g. for
unflattened subselects). As you increase the number of union partitions,
and therefore increase the number of base relations that have to be
included in the 30 range variables, the number of range variable slots
available for secondary indices decreases.

You can use trace point op156 (and search for 'GLOBAL VAR' in the
output) to see which relations are being chosen.

-----Original Message-----
From: info-ingres-admin (AT) cariboulake (DOT) com
[mailto:info-ingres-admin (AT) cariboulake (DOT) com] On Behalf Of Roy Hann
Sent: 21 March 2005 12:52
To: info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] Strange change in QEP of unioned subselects

<Piotr.Wisniewski (AT) breat (DOT) com.pl> wrote

Quote:

Ingres 2.6 on SunOS

There is a SELECT statement of type
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT...

Each subselect references several tables.The list is the same for each
subselect.
The qep is correct. The execution of each subselect begins from a
secondary
index on table U.

Now add 'create table tmp_000 as..' at the beginning of this statement
and the qep changes to bad: no use of the index, the execution starts
from
Proj-rest node on table U.

Is that bad? The use of an index is not automatically a good thing.
Quite
often it is a (very) bad thing. What happens to the response time?
Can we
see the two different sets of QEPs?

Quote:

I suspect we reach some internal limit of the number of tables
referenced

in

Quote:

qep. Is there any other explanation ?.

There is a limit on the number of range variables in a query (30 in your
version), but if you exceed it the query just fails. Adding more tables
to
the query can perturb the order in which candidate query plans are
generated, so if the OPF times out you can end up with a different plan.
Did it time out?

Quote:

Note that the qep remains ok if we add 'create table as ..', but
reduce

the

Quote:

number of subselects to 3.

See above.

Roy Hann (rhann at rationalcommerc dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

#8

Thank you Keith.
It's much more clear for me now.
My plan is to recreate the index idx_t161_01
and rename it to idx_t161_03 to make room for the idx_t161_02
which I need in qep.

Piotr

-----Original Message-----
From: Hayden, Keith C [mailto:Keith.Hayden (AT) ca (DOT) com]
Sent: Monday, March 21, 2005 4:09 PM
To: Piotr.Wisniewski (AT) breat (DOT) com.pl; info-ingres (AT) cariboulake (DOT) com
Subject: RE: [Info-ingres] Strange change in QEP of unioned subselects

Hi Piotr,

Try searching for 'grv:' (grv = global range variable) in the op156
output and you may see the entries for 29 and 30. These may be temporary
relations used in the creation of the temp table.

As you have seen, the number of range variables allowed is 32 (0 -> 31)
rather than 30 - 30 is the parser's limit for user defined base
relations, whereas the query optimizer allows 32 base relations, temp
relations and secondary indices.

Thanks,
Keith.

-----Original Message-----
From: Piotr.Wisniewski (AT) breat (DOT) com.pl
[mailto:Piotr.Wisniewski (AT) breat (DOT) com.pl]
Sent: 21 March 2005 14:44
To: Hayden, Keith C; info-ingres (AT) cariboulake (DOT) com
Subject: RE: [Info-ingres] Strange change in QEP of unioned subselects

I did that plus some greping and I see my index falls out when there is
'create table .. as ' (VAR=31 name: idx_t161_02) below.
Why there is the hole between number 28 and 30/31 ?

Version without 'create table':
GLOBAL VAR=24, RDR_INFO: DMT_TBL_ENTRY: table name=
fund_price_unit_hist_03
GLOBAL VAR=25, RDR_INFO: DMT_TBL_ENTRY: table name=
instruction_type_dir_02
GLOBAL VAR=26, RDR_INFO: DMT_TBL_ENTRY: table name=
inv_instr_commission_07
GLOBAL VAR=27, RDR_INFO: DMT_TBL_ENTRY: table name= sale_instr_054,
id-base
GLOBAL VAR=28, RDR_INFO: DMT_TBL_ENTRY: table name= batch_register_051,
id-
GLOBAL VAR=30, RDR_INFO: DMT_TBL_ENTRY: table name= idx_t161_01,
id-base=14
GLOBAL VAR=31, RDR_INFO: DMT_TBL_ENTRY: table name= idx_t161_02,
id-base=14
OPV_GLOBAL_RANGE: base=525006848, num=32

Version with 'create table':
GLOBAL VAR=22, RDR_INFO: DMT_TBL_ENTRY: table name=
investor_unit_acct_021,
GLOBAL VAR=23, RDR_INFO: DMT_TBL_ENTRY: table name=
investor_accounts_019,
GLOBAL VAR=24, RDR_INFO: DMT_TBL_ENTRY: table name=
fund_price_unit_hist_03
GLOBAL VAR=25, RDR_INFO: DMT_TBL_ENTRY: table name=
instruction_type_dir_02
GLOBAL VAR=26, RDR_INFO: DMT_TBL_ENTRY: table name=
inv_instr_commission_07
GLOBAL VAR=27, RDR_INFO: DMT_TBL_ENTRY: table name= sale_instr_054,
id-base
GLOBAL VAR=28, RDR_INFO: DMT_TBL_ENTRY: table name= batch_register_051,
id-
GLOBAL VAR=31, RDR_INFO: DMT_TBL_ENTRY: table name= idx_t161_01,
id-base=14
OPV_GLOBAL_RANGE: base=525006848, num=32

-----Original Message-----
From: Hayden, Keith C [mailto:Keith.Hayden (AT) ca (DOT) com]
Sent: Monday, March 21, 2005 2:41 PM
To: info-ingres (AT) cariboulake (DOT) com
Subject: RE: [Info-ingres] Strange change in QEP of unioned subselects

The limit of 30 range variables that Roy describes below is for all
relations: base tables, secondary indices and temporary tables (e.g. for
unflattened subselects). As you increase the number of union partitions,
and therefore increase the number of base relations that have to be
included in the 30 range variables, the number of range variable slots
available for secondary indices decreases.

You can use trace point op156 (and search for 'GLOBAL VAR' in the
output) to see which relations are being chosen.

-----Original Message-----
From: info-ingres-admin (AT) cariboulake (DOT) com
[mailto:info-ingres-admin (AT) cariboulake (DOT) com] On Behalf Of Roy Hann
Sent: 21 March 2005 12:52
To: info-ingres (AT) cariboulake (DOT) com
Subject: Re: [Info-ingres] Strange change in QEP of unioned subselects

<Piotr.Wisniewski (AT) breat (DOT) com.pl> wrote

Quote:

Ingres 2.6 on SunOS

There is a SELECT statement of type
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT....
UNION ALL
SELECT...

Each subselect references several tables.The list is the same for each
subselect.
The qep is correct. The execution of each subselect begins from a
secondary
index on table U.

Now add 'create table tmp_000 as..' at the beginning of this statement
and the qep changes to bad: no use of the index, the execution starts
from
Proj-rest node on table U.

Is that bad? The use of an index is not automatically a good thing.
Quite
often it is a (very) bad thing. What happens to the response time?
Can we
see the two different sets of QEPs?

Quote:

I suspect we reach some internal limit of the number of tables
referenced

in

Quote:

qep. Is there any other explanation ?.

There is a limit on the number of range variables in a query (30 in your
version), but if you exceed it the query just fails. Adding more tables
to
the query can perturb the order in which candidate query plans are
generated, so if the OPF times out you can end up with a different plan.
Did it time out?

Quote:

Note that the qep remains ok if we add 'create table as ..', but
reduce

the

Quote:

number of subselects to 3.

See above.

Roy Hann (rhann at rationalcommerc dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

_______________________________________________
Info-ingres mailing list
Info-ingres (AT) cariboulake (DOT) com
http://mailman.cariboulake.com/mailm...py/info-ingres

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

[Info-ingres] Strange change in QEP of unioned subselects

comp.databases.ingres comp.databases.ingres

[Info-ingres] Strange change in QEP of unioned subselects - 03-21-2005 , 06:26 AM

Re: [Info-ingres] Strange change in QEP of unioned subselects - 03-21-2005 , 06:52 AM

RE: [Info-ingres] Strange change in QEP of unioned subselects - 03-21-2005 , 07:41 AM

RE: [Info-ingres] Strange change in QEP of unioned subselects - 03-21-2005 , 07:51 AM

Re: [Info-ingres] Strange change in QEP of unioned subselects - 03-21-2005 , 08:40 AM

RE: [Info-ingres] Strange change in QEP of unioned subselects - 03-21-2005 , 08:43 AM

RE: [Info-ingres] Strange change in QEP of unioned subselects - 03-21-2005 , 09:09 AM

RE: [Info-ingres] Strange change in QEP of unioned subselects - 03-21-2005 , 09:13 AM