인덱스를 어떤 컬럼에 걸었는지.. 그리고 구체적인 검색 SQL문은 무엇인지 알려주셔야 구체적으로 알 수 있을 것 같네요.

그리고 explain 결과를 알려주시면 더욱 좋구요.

그리고 vacuum -f는 서비스 중에는 하면 안됩니다. vacuum -z를 하세요.

-f 옵션은 서비스를 내리고 돌려야 합니다.

그리고 mysql이랑 비교했을 때에 pgsql이 검색은 그렇게 느리지 않습니다. insert는 많이 느리구요. 시험 삼아서 mysql에서도 같은 작업을 해보시는 것도 좋겠지만 검색 속도가 느려서라면 큰 차이는 없지 않을까 생각합니다.

그리고 개인적인 판단에는 단순히 다량의 로그를 쌓아 두고 단순한 질의만 하는 것이라면 MySQL이 더 적절할 것 같습니다. 트렌젝션도 필요 없고... 다중 join의 다중 질의도 필요 없다면... 오직 속도가 중요하다면 MySQL도 좋은 선택이라고 생각합니다. 동시 사용자가 많아지고 쿼리가 조금만 복잡해지면 성능이 급격하게 떨어지지만 말입니다.

물론 log만 쌓아두는 목적이 아닌 다른 용도도 포함된다면 pgsql이겠지요.

vacuum full 을 하면 멈춘것처럼 보이는게 아닐까요?

vacuum이 끝날 때까지 다른 질의가 모두 기다리게 되버리니까..

7가지가 넘는 인덱스의 모든 정보도 알아야 겠는데요 -.-;

근데 그냥 딱 보니 테이블이 좀...

date 라는 필드는 그냥 date 타입으로 맹거줘도 되지 않나 싶네요.. 4바이트와 10바이트는 =_=;;

아니면 date+hour+time 을 timestamp 로 해도 되구요.. 시간으로 검색하려면 시간만 뽑아서 따로 인덱스를 잡아도 되구요..

테이블 구조를 많이 바꾸면 훨씬 좋은 방법이 나올것 같습니다.

신기배님.. 역시... 이 늦은(또는 이른? ^^) 시간에 보면서도 테이블 구조를 자세히 보셨네요. 대단하십니다.

저는 눈에 전혀 안들어 오네요... 가물 가물... 안녕히 주무세요.

인덱싱은 한 20개정도 되는군요. 넘 많은가..하지만 다 필요한 항목입니다.

_date, time, hour를 나눈것은 별도로 검색을하는 부분이있기 때문이구요.

이것을 합치면 웹에서 분리해야하기땜시. 더 느릴거 같아서요.

보시다시피 log를 저장하는 테이블이라. 아주 단순합니다.

vacuum -f를 하여 멈추어보인다면..음..

자료가 많아서 시간이 엄청 걸리는데.. vacuum -f가 끝난다음에 insert가 정상적으로 이루어질까 의문이군요.

인터넷으로 찾아보니까. 역색인을 걸면 빠르다고하는데. 어떻게하는것인지..

아래처럼 인덱싱하나 걸고 질의할적에 만 아래와같이 사용하면 되는것인쥐.....

이렇게 해서는 별 성능의 이점이 없던데...

고민이 많군요. 하루에 300만 이상의 자료를 한달정도 보관해야하는데...

도움될 조언을 부탁합니다.

SELECT /*+ INDEX_DESC (logs logs_idx) */ count(*) FROM log WHERE
test5 = 'domain.com';

CREATE INDEX logs_idx_1 ON log USING btree (_date);
CREATE INDEX logs_idx_2 ON log USING btree (_date, test3);
CREATE INDEX logs_idx_3 ON log USING btree (_date, test6);
CREATE INDEX logs_idx_4 ON log USING btree (_date, test7);
CREATE INDEX logs_idx_5 ON log USING btree (_date, test10);
CREATE INDEX logs_idx_6 ON log USING btree (_date, test9);
CREATE INDEX logs_idx_7 ON log USING btree (_date, test3, test5);
CREATE INDEX logs_idx_8 ON log USING btree (_date, test4, test5);
CREATE INDEX logs_idx_9 ON log USING btree (_date, test6, test5);
CREATE INDEX logs_idx_10 ON log USING btree (_date, test5, test7);
CREATE INDEX logs_idx_11 ON log USING btree (_date, "hour");
CREATE INDEX logs_idx_12 ON log USING btree (_date, "hour", test10);
CREATE INDEX logs_idx_13 ON log USING btree (_date, "hour", test11);
CREATE INDEX logs_idx_14 ON log USING btree (_date, "hour", test13);
CREATE INDEX logs_idx_15 ON log USING btree (_date, "hour", test10);
CREATE INDEX logs_idx_16 ON log USING btree (_date, "hour", test5);
CREATE INDEX logs_idx_17 ON log USING btree (_date, "hour", test6, test7);
CREATE INDEX logs_idx_18 ON log USING btree (_date, "hour", test8, test9);
CREATE INDEX logs_idx_19 ON log USING btree (_date, "hour", test10, test11);
CREATE INDEX logs_idx_20 ON log USING btree (_date, "hour", test9, test8);

다시 말씀 드리지만 vacuum -f는 운영 중에는 전혀 할 필요 없구요. 해서도 안 됩니다. vacuum -f와 그냥 vacuum의 차이는 필요없는 디스크 공간을 돌려받을 수 있다는 의미 외에는 없다고 보시면 되구요. delete나 update가 거의 없고 insert나 select만 있다면 (지금의 경우 그런 것 같네요) 그 효과는 더욱 미비합니다. vacuum -z를 하세요.

그리고 보여주신 질의는 oracle용 같네요. /*+ ... */ 와 같은 hint는 오라클에서나 되는 기능입니다.

그리고 인덱스가 많다고 select가 느려지지는 않습니다. 오히려 insert가 느리지요.

그런데 보여주신 쿼리문을 보면 조건이 test5='domain.com' 밖에 없는데요. 인덱스 중에는 쓸 수 있는게 하나도 없네요. 모두 f_date가 주 색인 컬럼이네요. 이래가지고는 full seq. scan 밖에 방법이 없어서 엄청 느려질 것 같네요..

create indedx logs_idx_test5 on log (test5);

이렇게 색인 만드시고...

vacuum -z

하신 후에 다시 해보세요.