Cartesian Join query optimization

Question

Hello Experts!
I have a question about cartesian join query which might look a bit weird.
Assume the SQL query like that:
SELECT DISTINCT A.NAME
FROM A, B, C;
Here we have cartesian join for 3 tables A, B and C.
It looks to me, in order to get the result for such a particular SQL tables/sets B and C need to be accessed only to ensure they return at least 1 row (otherwise result set is empty), query table A, but there is no actual need to join the data.
If you run such a query Oracle is doing full table scans and actually joins the data.
Yes, DBMS is doing exactly what you are asking for, but I wonder if there is any way (SQL hint or db parameter or anything else) to enforce more optimal access path here?
Obvious solution to remove B and C tables from the SELECT statement is not acceptable. :-)
Thank you!

Answer 1

Your statement in the other thread indicates you don't understand how the BI prompts actually work because you say you want it to do something that doesn't make sense for it to do.
Of course Product and Account levels will be constrained to the interval you specified. It wouldn't make sense for them not to be. Because that would mean returning data for based on product and account levels that has a different open data range than what you specified.
All UI prompt dialogs I have seen use AND relationships between the parameters. If there are three parameters (A, B, C) then the ultimate relationship is 'A AND B AND C'; not 'A OR (B AND C)', 'A AND (B OR C)', 'A OR (B OR C).
Unless the tool allows you to select OR relationships you need to use a separate dialog box (parameter dialog) for each condition set.:-)
I understand how BI prompts work and basically agree on your comment, but there are two problems here:
1. I need to convince the customer his original requirements are not valid. Customer want it to work different way and there are some reasons why.
2. There are pretty large dimensions and fact tables used here, so when I choose filter criteria for the Product (which is small table) to populate/recalculate prompt values, large SR dimension and fact tables are joined too, and if there are Account dimension filters added, huge Account dimension will be added as well. This looks to be a bit sub-optimal for just populating the Product prompt values.
Of course, technically this is solvable, but requires to put some extra effort and does not solve the 1st issue.
That other link doesn't explain the sample code you posted in this thread. Post the actual query that is being generated and the query that you want to actually use.This is what is generated:
>
select distinct T311691.X_CUST_SUBTYPE as c1
from
WC_LOV_SR_AREA_H T311695,
WC_LOV_PROD_H T311687,
WC_LOV_CUST_TYPE_H T311691,
W_SRVREQ_D T302384 /* Dim_W_SRVREQ_D */
where ( T311687.LEV1 = 'Product X' and T311691.X_CUST_TYPE = 'Business' and T302384.OPEN_DT between TO_DATE('2012-03-01 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') and TO_DATE('2012-03-31 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') )
order by c1
>
This is what is actually needed to query this data:
>
select distinct T311691.X_CUST_SUBTYPE as c1
from
WC_LOV_CUST_TYPE_H T311691
where ( T311691.X_CUST_TYPE = 'Business' )
order by c1