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
운영게시판
최근게시물
PostgreSQL Q&A 10304 게시물 읽기
No. 10304
postgresql 로딩
작성자
192hkh
작성일
2021-12-08 13:47
조회수
1,429

똑같은 쿼리인데도 불구하고 조건절에 원하는 값을 '1' 로 했을 경우에는 바로 결과가 출력되고

'2'로 했을 때는 결과값도 산출안될 뿐더러 오류메세지조차 뜨지 않은 채 로딩바만 계속 돌아가는데

아무리봐도 그럴 이유가 없어서 의문입니다. 어떤 경우에 이런 상황이 발생하나요? 

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

많은 경우에 그래요. 

정보가 너무 빈약해서 

그 많은 경우를 모두 이야기 해드릴 수가 없네요.

김상기(ioseph)님이 2021-12-08 14:53에 작성한 댓글입니다.

번거로우시겠지만 대표적인 경우 조금만 부탁드려도될까요?

컬럼값이 1인것과 2인것의 데이터 개수 차이는 약소합니다.. 테이블도 같은 테이블이라 

데이터타입도 동일하구요.. 쿼리문은 다음과 같습니다.. 

SELECT shp.rcpn_ymd, shp.grid_se_cd, shp.grid_id, shp.shp_cnt, fvsl.fvsl_cnt, (shp.shp_cnt + fvsl.fvsl_cnt) AS sum_cnt

FROM (SELECT rcpn_ymd, grid_se_cd, grid_id, SUM(shp_cnt) AS shp_cnt FROM lyr_center.tb_daly_ecdt_bas WHERE shp_knd NOT IN ('00','01') AND rcpn_ymd = '20200101' GROUP BY rcpn_ymd, grid_se_cd, grid_id) AS shp, 

(SELECT rcpn_ymd, grid_se_cd, grid_id, SUM(shp_cnt) AS fvsl_cnt FROM lyr_center.tb_daly_ecdt_bas WHERE shp_knd IN ('00','01') AND rcpn_ymd = '20200101' GROUP BY rcpn_ymd, grid_se_cd, grid_id) AS fvsl

WHERE shp.rcpn_ymd = fvsl.rcpn_ymd AND shp.grid_id = fvsl.grid_id; 

위의 예시는 쉽게 설명하고자 했던거고 실제로 조건절에서 바뀌는건 위의 쿼리의 '20200101' 이 '20180101'로 바꾼경우입니다 

192hkh님이 2021-12-08 15:27에 작성한 댓글입니다.
이 댓글은 2021-12-08 15:36에 마지막으로 수정되었습니다. Edit

가장 대표적인 경우가 2가 들어있는 데이터블록을 못 읽는 경우겠지요. 

그 다음 대표적인 경우가 해당 작업이 테이블 전체 순차 탐색을 하지 않고, 인덱스 탐색을 하는데, 그 인덱스 블록을 못 읽는 경우일 것이고, 

select * from 인 경우, 1이 들어있는 row와 2가 들어있는 row의 한 row 크기가 왕창 차이가 나는 경우도 있고, 

예를 들어, 1,2가 들어있는 col1, 이고, 그 row의 text 형 자료가 저장되는게 col2 인데, 이 col1 = 2 인 자료의 col2에 어마어마한 자료가 담겨 있는 경우입니다. 

col1 = 1 인 자료에는 col2 에 아무것도 없고. 그럼 속도 차이는 현저할겁니다. 

그 외에도, 

각종 하드웨어 문제일수도 있고, 중간에 거치는 네트워크 장비에서 패킷에 따라 오동작을 할 수도 있고,

자료량에 따른 보안 정책으로 보안 장비가 막는 경우 같은 정책 문제 일 수도 있고, 

복잡한 쿼리를 잘못해석하는 데이터베이스 버그일 수도 있고, 

데이터파일의 dead tuple 처리를 잘못 처리하는 버그일 수도 있고,

autovacuum worker 프로세스가 비정상 멈춤 상태인데, 하필이면 그 자료가 2번 자료를 건드리고 있는 상황일 수도 있고, 

더 나아가, 

2 번 자료가 다른 응용 프로그램에 select 도 금지하는 row lock을 취득해서 대기하는 지극히 정상적인 상황도 있습니다. 


원인이 밝혀지면 공유부탁드려요. 

제가 찍은 경우들 가운데 하나일지, 아니면, 또 다른 경우일지가 궁금하네요. 


제일 먼저 해야하는 작업은  

1,2일때의 실행계획이 바뀌는지를 확인하는 일이고, 

다음 어떤 네트워크도 통하지 않는 로컬 환경에서 그 테이블과 실행계획에서 사용하는 각종 객체들이 모두 잘 읽을 수 있는지를 확인해 보는 것입니다. 

이미 여기서 문제라면, 그 dump가 왜 안되는지부터 확인해봐야합니다. 

lock 문제인지, 물리적 장애인지, 정책 문제인지.... 


좋은 질문이 좋은 답변을 얻습니다.

김상기(ioseph)님이 2021-12-08 15:47에 작성한 댓글입니다.

성의없는 질문에 성심성의껏 답변해주셔서 감사합니다. 

제가 부족한 탓에 잘 설명해주셨음에도 100%를 이해하지 못했지만, 말씀해주신것처럼 이것저것 확인해봐야겠네요. 혹시 해결하게 된다면 공유드리겠습니다! 다시한번 감사합니다.

192hkh님이 2021-12-08 15:52에 작성한 댓글입니다. Edit

실행계획 살펴보니 조건값만 바뀌는데도 실행계획이 바뀌어버리네요..

쿼리 자체를 손봐야할까요? 비전공 학생신분이라 무지함에 부끄럽습니다.

192hkh님이 2021-12-08 15:59에 작성한 댓글입니다. Edit

저 날짜가 바뀜에 따라 실행계획이 달라지면서, 큰 테이블을 순차적으로 모두 탐색하는 경우도 있을 수 있겠네요. 


실행 계획은 

explain 쿼리 

명령으로 확인합니다. 


통상 저런 문제의 접근은 

select count(*) from lyr_center.tb_daly_ecdt_bas WHERE shp_knd NOT IN ('00','01') AND rcpn_ymd = '20200101'

select count(*) from lyr_center.tb_daly_ecdt_bas WHERE shp_knd NOT IN ('00','01') AND rcpn_ymd = '20180101'

select count(*) from lyr_center.tb_daly_ecdt_bas WHERE shp_knd IN ('00','01') AND rcpn_ymd = '20200101'

select count(*) from lyr_center.tb_daly_ecdt_bas WHERE shp_knd IN ('00','01') AND rcpn_ymd = '20180101'


네 쿼리가 일단 정상 작동하는지부터 확인해 봐야할 것 같네요.


모두 정상이면, 

마지막 두 인라인뷰의 rcpn_ymd, grid_id 만 join 대상이 되어 grid_se_cd 대상으로 묻지마 join을 하게 되면서 문제가 생겼을 수도 있겠네요. 

내부 두 인라인뷰의 row수 * row수 만큼의 자료를 만들겠네요.

김상기(ioseph)님이 2021-12-08 16:03에 작성한 댓글입니다.
postgres=# create table a (a int, b int , c int);
CREATE TABLE
postgres=# create table b (a int, b int, c int);
CREATE TABLE
postgres=# insert into a values (1,1,1),(1,1,2),(1,1,3);
INSERT 0 3
postgres=# insert into b values (1,1,1),(1,1,2);
INSERT 0 2
postgres=# select * from a, b where a.a = a.a and a.b = b.b;
+---+---+---+---+---+---+
| a | b | c | a | b | c |
+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 1 | 1 |
| 1 | 1 | 1 | 1 | 1 | 2 |
| 1 | 1 | 2 | 1 | 1 | 1 |
| 1 | 1 | 2 | 1 | 1 | 2 |
| 1 | 1 | 3 | 1 | 1 | 1 |
| 1 | 1 | 3 | 1 | 1 | 2 |
+---+---+---+---+---+---+
(6개 행)
김상기(ioseph)님이 2021-12-08 16:08에 작성한 댓글입니다.

제가 놓쳤네요. 

쿼리는 당연히 잘 짰다는 것을 가정하다니!


값을 바꿨는데, 결과가 안나와야요 - 정말 내가 원하는 결과를 찾는 쿼리가 맞는지 먼저 살펴보세요. :)

김상기(ioseph)님이 2021-12-08 16:15에 작성한 댓글입니다.

네 쿼리가 모두 정상적으로 작동합니다. 

마지막 WHERE 구절에서 rcpn_ymd 와 grid_id 말고 grid_se_cd 까지 같다는 조건으로 돌렸는데 실행이 안됐었습니다.. 근데 grid_se_cd는 사실 없어도 되는 조건인 것 같아 생략했더니 그래도 해결이 안되었어요.. 

실행계획은 20200101은 Merge join으로 시작하는데 20180101은 Nested Loop로 시작하는데 뭐가 문제일까요.. 

너무 감사해서 성의를 표하고싶은데 카톡ID는 개인정보때문에 불편하시다면 메일주소라도 남겨주시면 약소하게나마 감사한 마음을 표하고 싶습니다. 

192hkh님이 2021-12-08 16:17에 작성한 댓글입니다. Edit

쿼리는 원하는 결과가 맞습니다ㅜ

192hkh님이 2021-12-08 16:24에 작성한 댓글입니다. Edit

윗 문제는 일단, grid_se_cd 칼럼이 join 절에서 왜 빠졌는지 확인하는 거에요. 

그게 들어가면, 상황이 달라질 것 같네요. 


select count(*) from lyr_center.tb_daly_ecdt_bas where  rcpn_ymd = '20200101' 


2018년의 자료가 얼마나 차이 나는지를 살펴보는 것이고. 

...

차근하게 grid_se_cd 칼럼이 빠지면서 갑자기 결과 집합이 왜 확 많아지는지를 살펴야할 것 같아요. 


더 깊게 공부할 요량이면 원자료 말고, 샘플 자료 대여섯개 가지고 확인해보세요. grid_se_cd 문제가 뭔지 확인할 수 있을겝니다.


>> 근데 grid_se_cd는 사실 없어도 되는 조건인 것 같아 생략했더니 그래도 해결이 안되었어요.. 

그럼 쿼리문 전체에서 아에 grid_se_cd 라는 글자가 하나도 없게 해서 확인해보세요. 

 

김상기(ioseph)님이 2021-12-08 16:34에 작성한 댓글입니다.
이 댓글은 2021-12-08 16:37에 마지막으로 수정되었습니다.

자료차이는 크지않습니다.. 오히려 더 많은 데이터도 조회가 되었구여ㅠ

염치없이 더 이것저것 여쭙고 도움받고싶지만 이미 너무 많은 실례를 범한거 같아 

열심히 뒤적거려야겠네요 ㅎㅎ 메일주소를 부탁드려도 될까요 성의를 표하고 싶습니다. 

grid_id 컬럼에 grid_se_cd 에 대한 내용도 내포되어있어 grid_id를 조인걸면 grid_se_cd는 자동으로 같은 값끼리 엮이게 되어 필요가 없습니다. 근데 결과값 표출은 grid_se_cd 도 필요하여 빼기 곤란한 상황이네요 .. 혹시 모르니 빼고 돌려는 보겠습니다. ->안되네요 ㅠ

192hkh님이 2021-12-08 16:40에 작성한 댓글입니다.
이 댓글은 2021-12-08 16:43에 마지막으로 수정되었습니다. Edit

성의는 자신의 삽질기를 다른 사람들도 읽으라고 공개하는 것으로 충분합니다. :)


일단 각 inline view 들이 잘 작동하는지부터 확인을 해봐야겠네요. 


다 잘 작동하는데, 

inline view의 결과를 각각의 create table as 명령으로 테이블로 만들고, 그 테이블들을 대상으로 join을 해보세요. 

그렇게 차근하게 하나씩 원인을 없애 가는 것이 문제점을 찾는 방법입니다. 

 

김상기(ioseph)님이 2021-12-08 16:58에 작성한 댓글입니다.

큰 도움되었습니다 .. 감사합니다 ! 

192hkh님이 2021-12-08 17:00에 작성한 댓글입니다. Edit

들어가는 데이터는 실행계획이 Merge join 이었고 안들어가는건 Nested loop 였는데

set enable_nestedloop = off 한 후 돌리니 결과값이 바로 산출되었습니다.

192hkh님이 2021-12-09 14:21에 작성한 댓글입니다. Edit
[Top]
No.
제목
작성자
작성일
조회
10307pg 안정화 버전 추천 부탁드립니다! [3]
김성아
2021-12-31
1340
10306인덱스 생성 시 에러가납니다 ㅜㅠ [3]
포스트초보
2021-12-14
1564
10305오류: 1114 블럭을 "base/16385/16536" 파일에서 읽을 수 없음: 0 / 8192 바이트만 읽음 [1]
황성범
2021-12-13
1453
10304postgresql 로딩 [15]
192hkh
2021-12-08
1429
10303pg_stat_user_tables Replication 복제 [4]
채상호
2021-12-06
1294
10302PgDay.Seoul 2021 온라인 행사 광고
김상기
2021-11-25
1478
10301locale 이 어렵네요 [1]
post
2021-11-24
1278
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.051초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다