1, 4 가 가장 쉬운 방법이군요 ^^;;

2번과 비슷한 방법을 사용은 하고 있습니다만.. 더 좋은 방법이 올라오면 좋겠습니다~

많은 생각을 해 보게 하는 제목이네요.

사실 정보라는 것이 존재한다는 것만으로 일반인들에게 도움이 될수는 없습니다. 현재 이 글은 이들 정보를 나열하는 방법에 대해서만 적은 듯 하네요.

가장 이상적인 것은 3번 일것 같구. 가장 쉬운 방법은 4번일 것 같네요. ^^;

낮에 상기님이랑 얘기한 대로 서버단과 클라이언트 단의 디비를 분리하면 어떨까 하는 생각을 해 봅니다. 서버단은 갱신의 속도가 빠른 놈으로 클라이언트단은 fetch, select 의 속도가 빠른 놈으로 ^^;;

그런데 이 둘간의 연동이 문제가 될것 같군요. 그리고 많은 insert/update 가 일어나는 환경이라면 이 또한 문제가 생기지 않을까요. 이런 경우의 해결점은 디비 서버 또한 분리하는 것이 답이 될수도 있겠네요.

여하튼 많은 작품 기대해 봅니다. ^^;

이렇게 공론화까지 해주시다니 몸둘바를 모르겠습니다. ^^

결국 저는 돈두 없구 빽두 없어서 연도별로 출력 하기로 했습니다. ^^

근데 limit offset의 알고리즘은 바껴야 할것 같네요 .

다들 머리에 빨간띠 두르고 투쟁해야 하지 않을까요?

^_____^

제가 잘 몰라서 그러는데요.

pgsql외에 limit를 구현한 DB가 mysql이외는 본적이 없는데 mysql에서는 offset값이 커도 성능의 차이가 없나요? 제 생각으로는 역시 성능의 차이가 있을 것 같은데...

그리고 커서를 사용하는게 limit를 사용하는 것 보다 빠를까요? 제가 단순하게 판단하기로는 limit를 써도 내부적으로 커서를 사용할 것 같습은데요.

결국 제 의견은 limit가 offset의 값에 따라 성능이 늘려지는 상황이라고 하더라도 2번 같은 방법이 아닌이상 외부적언 그 어떤 방법 보다는 빠르거나 같지 않을까요? 3번 같은 방법 보다 말입니다.

그리고 2번 같은 경우도 인덱스만 잘 만들고 질의 조건에 날자를 주어서 질의 대상만 축소해 준다면 별도로 table을 만들 필요까지는 없지 않을까 생각해 봅니다. 별도로 만들면 약간의 성능 향상은 있겠지만 자료구조가 복잡해지니 그 부담도 있겠죠.

킁.. 많이 적었는데 회사 인터넷이 갑자기 끊겨서 다 날아가버렸습니다 =_=;

mysql도 offset 값이 크면 느려집니다.

limit이 내부적으로 커서를 사용하는지는.. 저도 모르겠습니다 -.-;

하지만 내부적으로 limit이 커서를 사용한다고 해도 두가지는 엄연히 다를수 밖에 없는게.. limit은 단발성입니다. 연산이 끝나고 나면 그 커서도 소멸?

하지만 콘넥션 풀이나 영구적인 접속등으로 한번 커서를 얻어 놓고 계속 이를 쓸수 있다면 limit은 비교대상이 못되겠죵 -.-

그런 의미에서.. limit쪽을 처리하는 부분.. 소스를 좀 디벼바야겠습니다 ㅡㅡㅋ

limit offset 알고리즘 이야기는

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

윗 글 코멘트에서 하고 있습니다. 내부 커서가 있었다면, offset 값이 커졌다고 속도가 느려지지는 않겠지요. :)

limit의 알고리즘 이야기를 잘 읽었습니다.

그런데.. 제가 pgsql의 내부를 본 적도 없고 잘 만들었을 것이라고 확신하는 것도 아니지만... 보여주신 글에 대해서는 잘 동의가 되지 않네요.

사례 1은 index를 타고 사례 2는 index를 타지 않아 sort와 sequence scan이 이뤄지는 바람에 속도차이가 난 것인데 사례 1은 전체의 포인터를 기억하고 있는 방식이고 사례2는 offset 만큼 skip하고 차례로 보여주는 방식이라고 설명 하셨습니다. 그런데 오히려 반대 아닌가요?

사례 1은 index scan을 하기 때문에 index를 순서대로 타면서 offset 만큼 이동하다가 필요한 자료를 반환하는 방식이고 사례2는 sort 를 위해서 전체 자료를 한번 다 참조를 하고 다시 sequnce scan을 하는 데요. explain을 보면 사례 2의 대부분은 sort하는데 걸린 시간입니다.

여전히 offset이 커질때에 왜 index를 안타는지는 의문이 되는 상황이지만 limit offset 알고리즘에 대한 설명은 한번 더 생각해 봤으면 합니다.

제 생각에는 내부적으로 offset값이 커지면 index scan보다는 sequence scan이 더 빠르니 optimizer가 sequence scan을 선택하는 것이 낫다고 생각을 했는데 order by 절 때문에 소트가 이뤄지는 바람에 오히려 속도가 늦어진 것 아닌지 판단이 됩니다. 일반적인 경우 index scan보다 sequence scan이 10배 이상 빠른 것으로 알고 있습니다. 다만 보여주신 사례에서는 index scan보다 소트 후에 sequence scan을 하는 것이 비용이 적게 들어서 그렇게 선택한 듯 합니다. optimizer의 판단이 맞는지는 모르겠지만 index scan을 했더라도 아마 비슷한 속도가 나오지 않았을까 생각합니다.

결국 제 생각에 offset이 커지면 느려지는 이유는 limit, offset의 알고리즘 보다는 index scan을 했을 때에 일정 수준이 넘으면 급격하게 성능이 떨어지는 pgsql의 문제 때문이 아닐까 생각합니다.

그러니 optimizer가 offset이 커지면 index scan을 믿지 못하고 차라리 소트를 하는게 낫다고 생각하는 것이겠지요.

해법을 제시 안했군요.

뭐.. 이것을 해법이라고 할 수 있을지 모르겠지만..

sort 메모리를 많이 잡아주면 optimizer가 sequence scan을 선택해서 sort가 이뤄지더라도 sort 성능이 높아지니까 도움이 많이 될 것으로 생각합니다.

또하나는 temporary table을 만드는 것입니다. limit, offset을 주지 말고 모든 row의 id를 insert into... select... 구문으로 temporary table에 넣은 다음 offset위치에서 필요한 개수 만큼 얻어오는 방법...

CREATE TEMP TABLE t_id_list

(

idx SERIAL,

id integer

);

INSERT INTO t_id_list (id)

SELECT id FROM MyTable WHERE ....;

select id from t_id_list where idx >= 2000 limit 100;

이렇게 얻은 id로 다시 자료을 읽어오면 쓸만한 시간에 자료을 읽을 수 있을 것 같네요.

sort에 대한 또 하나 방법은...

만약 순서가 항상 일정하다고 한다면 cluster 명령으로 table의 저장 순서를 아에 특정 index에 맞춰서 저장되도록 하는 것은 어떨지요. 이렇게 되면 sort가 생각되고 바로 sequence scan으로 넘어가기 때문에 속도가 엄청 좋아지리라고 생각합니다만...

cluster를 한 다음에는 analyze를 꼭 해야합니다.

자꾸 오타가...

위에.. 'sort가 생각되고' 가 아니고 'sort가 생략되고' 입니다.

그런데.. 비슷한 상황에서 mysql은 어떤지 궁금하네요.... 과연 속도에 변화가 없을지...

제 이야기가 박성철님의 이야기하고 같은데요.

초점은 limit offset 알고리즘이 개선된다면, 그것도 대용량 자료에 촛점이 맞추어진다면,

select 결과물 전체에 대해서 박성철님의 임시 테이블 같은 놈이 내부적으로 메모리에 만들어지고,(물론 RDBM의 테이블 스키마 같은 놈이 아니라, 메모리의 일정 자료블럭이 되겠지요) offset 값에 따라 그 시작 위치를 바로 이동하는 형태로 가면, 10만건이든 100만건이든 limit offset 에 관계되어서는 속도가 똑같게 나오겠지요.

문제는 현재의 방식보다 비용이 많이 듭니다.

즉, 시스템 자체가 어느정도 받쳐줘야 어느정도 효과를 볼 수 있을터인데, 그 효과는 현재 그렇게 많지 않은 자료에서 얻는 효과보다 크지 않다고 판단되어서 바꾸지 않고 있나봅니다.