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 4814 게시물 읽기
No. 4814
[질문] 같은 쿼리문에서 이럴수 있나요?
작성자
강성일(elise75)
작성일
2003-07-29 09:47ⓒ
2009-09-11 10:24ⓜ
조회수
1,926

>>>> 1차 explain

explain analyze SELECT * FROM b_test2_board AS b1 order by topno, seq limit 15 offset 15000;

 

NOTICE: QUERY PLAN:

 

Limit (cost=31906.29..31938.19 rows=15 width=1207) (actual time=1387.72..1388.80 rows=15 loops=1)

-> Index Scan using b_test2_board_topseq on b_test2_board b1 (cost=0.00..54155.60 rows=25460 width=1207) (actual time=0.91..1290.71 rows=15016 loops=1)

Total runtime: 1389.26 msec

 

 .

>>> 2차 explain

explain analyze SELECT * FROM b_test2_board AS b1 order by topno, seq limit 15 offset 20000;

 

NOTICE: QUERY PLAN:

 

Limit (cost=39565.76..39565.76 rows=15 width=1207) (actual time=17942.09..17942.41 rows=15 loops=1)

-> Sort (cost=39565.76..39565.76 rows=25460 width=1207) (actual time=17171.49..17816.67 rows=20016 loops=1)

-> Seq Scan on b_test2_board b1 (cost=0.00..3412.60 rows=25460 width=1207) (actual time=2.60..2174.01 rows=25460 loops=1)

Total runtime: 18449.81 msec

 

 

offset 을 15000 까지 했을때는 index를 사용하는데 왜 offset 20000부터는 index 사용을 안하는걸까요. 다른 모든 조건은 같은 사항인데요 .

 

참고로 아래와 같이 인덱스 생성했습니다.

CREATE INDEX b_test2_board_idx_topno_seq ON b_test2_board USING btree (seq, topno);

 

고수님들의 조언을 바랍니다 .

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

이게 limit , offset 구문의 한계입니다.

저수준으로 생각할 때,

 

1. limit, offset 은 이미 전체 로우가 다 구해지고 나서 각 로우의 포인터를 기억하고 있다가 해당 offset의 포인터를 구해서 limit 만큼 보여주는 방법과,

 

2. 일단 쿼리 결과에서 무조건 offset 만큼 출력하지 않고, 계속 이동하다가 해당 offset이 되면 그때서 부터 limit 만큼 보여주는 방법

 

이 두가지 중 어느것이 비용이 적게 들까요?

 

당연히 2번이겠지요. 그래서, 결과적으로 result의 row 갯수가 많고(이 기준은 해당 PostgreSQL 서버의 시스템 환경에 달려있는 것같습디다) offset의 숫자가 크면 이놈은 인덱스를 사용하는 비용이나, 사용하지 않는 비용이나 마찬가지로 판단되기에서 파일을 적게 여는 인덱스를 사용하지 않는 것으로 처리됩니다.

(말이 무진장 꼬여있는게 잘 읽으시길)

 

최근에 저는 이 문제를 풀 한 방법으로 limit, offset을 포기해 볼까? 하는 생각을 조심스럽게 하기 시작했습니다. 대용량 자료에서는 limit offset 구문이 과연 의미가 있을까? 하는 생각을 최근 들어 자주 하게 되거든요.

 

아무튼 이문제는 테이블 설계자와 응용프로그램 개발자 스스로 풀어야할 문제입니다.

PostgreSQL의 limit offset 구현 방법이 변경되지 않는한 고쳐지지 않을 문제인듯싶습니다.

김상기(ioseph)님이 2003-07-31 15:53에 작성한 댓글입니다.

제 생각을 여기에 적어봤습니다. 도움이 될지는 모르겠지만 한번 참고해 보십시오.

http://database.sarang.net/?inc=read&aid=4823&criteria=pgsql&subcrit=qna&record_idx=4&currpg=0

박성철님이 2003-08-07 01:29에 작성한 댓글입니다.

order by와 index순서가 바뀌어있네요

 

index순서를 topno,seq로하면

offset에관계없이 index를탈검니다.

황치영(gau)님이 2003-08-08 22:48에 작성한 댓글입니다.

인덱스 생성문은

CREATE INDEX b_test2_board_idx_topno_seq ON b_test2_board USING btree (seq, topno);

아니라

CREATE INDEX b_test2_board_idx_topno_seq ON b_test2_board USING btree ( topno,seq);

가 맞습니다

강성일(elise75)님이 2004-01-27 14:53에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
4822저.. 이 에러좀 봐주세요.. [1]
양진웅
2003-08-01
1627
4821postmaster가 죽질 않아요.. [2]
양진웅
2003-07-30
1509
4816오라클의 데이터베이스 링크가 Postgre에도 있나요? [2]
김민성
2003-07-29
1715
4814[질문] 같은 쿼리문에서 이럴수 있나요? [4]
강성일
2003-07-29
1926
4813[질문]대형 텍스트는 어떻게 저장하져??? [2]
노동옥
2003-07-27
1684
4812windows 2003 iis에서 pg_connect() [1]
궁금이
2003-07-26
1550
4811[질문] table의 owner를 바꿀려면? [1]
박근준
2003-07-26
1433
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.016초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다