database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
ㆍInformix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Informix Q&A 2127 게시물 읽기
No. 2127
CASE 안에 들어가 있는 sub quary는 어떻게 처리되나요?
작성자
송찬의(jazzbluey)
작성일
2005-02-23 20:25ⓒ
2005-02-23 20:26ⓜ
조회수
8,528

 

QUERY:
------
SELECT SUBSTR(A.date_code,1,6) month_code ,
A.store_code store_code,
CASE WHEN A.dpt_code > 17 AND A.dpt_code < 25 THEN
(
select C.level1_code
from tb_goods_do C
where C.goods_code = A.goods_code
)
ELSE A.goods_code
END AS goods_code,
MAX(A.class_code ) class_code,
MAX(A.mgnt_type_code ) mgnt_type_code,
MAX(A.maker_code ) maker_code,
MAX(A.biz_code ) biz_code,
SUM(NVL(A.sale_qty, 0)) sale_qty,
SUM(NVL(A.sale_ramt,0)) sale_ramt
FROM tb_subl_fo_50 A
WHERE SUBSTR(A.date_code,1,6) BETWEEN SUBSTR("20050213",1,6)
AND SUBSTR("20050219",1,6)
GROUP BY 1,2,3

 

-----------------------------------------------------------------------------------


Estimated Cost: 372037
Estimated # of Rows Returned: 911
Temporary Files Required For: Group By

1) lgdw.a: SEQUENTIAL SCAN (Parallel, fragments: ALL)

Filters: (substr(lgdw.a.date_code , 1 , 6 ) >= '200502' AND substr(lgdw.a.date_code , 1 , 6
) <= '200502' )


# of Secondary Threads = 5

XMP Query Plan

oper segid brid width misc info
-----------------------------------------
scan 2 0 6 c

 

 

XMP Query Plan

oper segid brid width misc info
-----------------------------------------
scan 3 0 3 a
group 2 0 1
group 1 0 1

 

 


XMP Query Statistics

Cosvr_ID: 1
Plan_ID: 64948

type segid brid information
---- ----- ---- -----------
scan 3 0 inst cosvr time rows_prod rows_scan
---- ----- ---- --------- ---------
0 1 594 35334 35714
1 1 590 35957 36348
2 1 602 35601 35948
--------------------------------------
3 106892 108010

group 2 0 inst cosvr time rows_prod rows_cons mem ovfl tmp
---- ----- ---- --------- --------- --- ---- ---
0 1 423 105404 106273 104 0 0
-------------------------------------------------------------
1 105404 106273 (128)

group 1 0 inst cosvr time rows_prod rows_cons mem ovfl tmp
---- ----- ---- --------- --------- --- ---- ---
0 1 404 0 105378 0 0 0
-------------------------------------------------------------
1 0 105378 (200000)

 

질문: 위 Quary와 execution plan에서 Case 문 내부에 있는

select C.level1_code
from tb_goods_do C
where C.goods_code = A.goods_code

위의 Quary가 어떻게 실행될지 궁금합니다.

(goods_code에 index가 잡혀 있을 경우입니다)

 

몇가지 story가 가능한데...

 

첫째로 위 quary를 corelated subquary로 풀어서 A.goods_code가 상수로 하여 tb_goods_do의 C.goods_code를 이용하여 해당 record를 unique index search하는 경우.

 

둘째로 A.goods_code와 C.goods_code를 join하여 처리한다. 즉 optimizer가 위 쿼리를 join 방식으로 풀어서 매번 CASE문에 해당하는 경우마다 tb_subl_fo_50와 tb_goods_do를 nested loop join한다. 물론 이 경우는 A.goods_code는 상수가 아닌 변수로 간주.

 

위 explain plan을 참고하여 위 두가지 경우 중 어디에 해당하는지 설명해 주실 수 없을까요?

 

만약 혹시나 위 두가지 경우가 아니라면 다른 경우는 어떻게 처리할 수 있을까요?

 

고수님들의 친절한 답변을 기대합니다.


이 글에 대한 댓글이 총 1건 있습니다.

님의 쿼리상에서

 

Estimated Cost: 372037
Estimated # of Rows Returned: 911
Temporary Files Required For: Group By

1) lgdw.a: SEQUENTIAL SCAN (Parallel, fragments: ALL)

Filters: (substr(lgdw.a.date_code , 1 , 6 ) >= '200502' AND substr(lgdw.a.date_code , 1 , 6
) <= '200502' )

 

위와 같이 쿼리비용이 많이 발생하는 이유는

a.date_code 필드가 P.K 필드인것 같은데

substr을 사용해서 SEQUENTIAL SCAN  즉 Full Scan 과 거의 동일하게 타는것 같군요..

즉 P.K에 해당 필드 조건 걸때 위와 같이 함수를 사용하면 Index를 안타는걸루 알고 있습니다.

where 조건절을 다음과 같이 바꿔 쓰면 훨씬 빠를듯 보이네여..

where a.data_code between '20050201' and '20050228'

이런식으로만 해도 쿼리 무지 빨리 나올것 같네여..

 

님이 물어보는

a) 방식이나 b) 방식은 별 차이 없을듯 보이네여.

지나가다님이 2005-03-21 16:49에 작성한 댓글입니다. Edit
[Top]
No.
제목
작성자
작성일
조회
2130Informix 백업 문의드립니다.... [2]
남재훈
2005-03-05
8429
2129asp에서 레코드셋 관련 문의 [1]
코미트
2005-03-04
6923
2128피벗테이블을 SQL로
궁금이
2005-02-27
7257
2127CASE 안에 들어가 있는 sub quary는 어떻게 처리되나요? [1]
송찬의
2005-02-23
8528
2126일상적인 DBA점검 [1]
인포유저
2005-02-04
7124
2125Informix SQL Query 프로그램.
이호림
2005-02-02
9967
2124인포믹스가 Mysql보다 INSERT 가 느린 이유? [1]
현이
2005-02-02
7332
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2022 DSN, All rights reserved.
작업시간: 0.064초, 이곳 서비스는
	PostgreSQL v14.2로 자료를 관리합니다