어떤 식으로 table을 만드셨는지 궁금하네요.

인덱스는 적절했는지...

일단 인덱스를 점검해 주시구요.

data를 입력한 다음에 vacuum을 한번 해주시구요.

속편하게 vacuum full해서 전체를 정리하는 것이 좋을 것 같네요.

그리고 쿼리문의 비용 계산을 한번 해보세요. explain 명령으로요...

하지만 확실한 것은 단순한 구조에서는 mysql이 속도가 훨신 빠르다는거죠. 트렌젝션도 없고 포린키도 없고...

좀 더 자세한 정보를 보여주시면 여러 고수님들이 도와드릴 수 있을 것 같네요.

PostgreSQL 개발자 사용자 층은 비교적 유동적이지 않아 7.3.x 대가 나왔다 함은 그 만큼 오래 쓴 사용자들의 의견이 반영되어 나온다고 보는 것이 타당합니다. 처음에는 자료구조 상속이나, 지리정보에 촛점이 맞추어지더니, 다음에는 ANSI SQL 구현 쪽으로 그리고는 요즘은 대용량에 촛점이 맞추어지더군요.

그 첫번째 프로젝트가 테이블스페이스의 도입이고, 그 두번째가 쿼리 캐쉬입니다.

테이블스페이스 개념이 도입되어야 OS 비의존적인 자료를 구축할 수 있는지라, 대용량 DB에서는 필수적입니다. 하지만, 이것이 구현되기까지는 요원합니다.

쿼리 캐쉬는 대용량 자료 select에서는 거의 필수적으로 인식되고 있는 개념입니다. 오라클의 SGA 공간 같은 놈이 PostgreSQL에도 구현되어야 뭘 이야기해도 할 것인데, 이놈 또한 요원합니다. MySQL 쪽에서는 4.x 대로 바뀌면서 드디어 아주 기초적이나마 쿼리 캐쉬 기능을 지원하기 시작하더군요.

즉, 현재 상태로 본다면, 대용량 자료에 대한 RDBMS로 PostgreSQL 놈은 그 자격이 없는 샘이지요. 이것이 PostgreSQL 놈을 바르게 보는 견해입니다.

그렇다면, 현재의 PostgreSQL 이놈으로 어떻게 땜빵(!)할 것인가? 이것에 대한 이야기를 할 수 밖에 없는 것같습니다.

답은 간단합니다. 이곳 게시판, PostgreSQL 설명서 등에서 계속 이야기 하고 있는 지극히 단순한 개념들입니다.

1. 한꺼번에 많은 데이터를 테이블에 넣어야할 경우는 insert 구문 대신에 copy 구문을 이용한다.

insert 구문보다 copy 구문이 심하면 수백배 빠릅니다.

2. 사용하지도 않는 index는 만들지 않는다.

(update 구문 속도에 가장 영향을 주는 것이 index 입니다)

3. select 쿼리는 반드시 그 비용을 살펴보고 가장 빠른 쪽을 택하든지, 가장 비용이 적게 드는 쪽으로 선택한다.

4. 주기적인 vacuum으로 최적화된 데이터를 유지한다.

5. 같은 스케줄의 쿼리가 반복 된다면, prepare 구문을 이용해서 쿼리를 미리 준비해 둔다.

6. 통계관련 테이블을 적절히 이용한다. (대용량 데이터에서는 필수적이더군요)

제가 지금 생각나는 것은 이정도입니다.

개인적인 생각으로는 5백만건 단순 데이터(제약조건없고, foreign key 없고, 트리거 없고)를 가지고, MySQL과, PostgreSQL 비교한다면, 속도 면에서 PostgreSQL 놈이 당연히 뒤처지겠지만, 이것이 실무적인 관점에서 볼때, 업무에 지장을 초래할 만큼의 차이가 발생하리라고는 보지 않습니다.

지금까지 경험에 의하면, 백만건이 넘어가는 데이터를 가지고 실무에 사용될 때 PostgreSQL로 이용하는 것이 잃는 것 보다 얻는 것이 더 많았습니다.

실무에서 쓰이는 데이터는 단순한 자료구조가 별로 없거든요. 대부분 위에서 언급한 트리거에 의한 통계, foreign key, 제약조건들 ... 온갖 '관계에 대한 정보'들도 함께 포함되기 때문입니다.

너무 난해하게 글을 적은 모양이네여 ^^;;

데이터 입력은 copy from stdin 으로 시작되는 파일을 \i 로 입력 받은 거구용 ^^;;

pgsql의 insert 속도는 fsync 를 꺼도.. 크으 -_-;;

테스트의 목적은 사용자의 검색만을 담당할 DBMS를 분리 하자는데 목적을 두고 시작하였고 update나 insert가 일어날 경우에도 select에는 아무런 문제가 없어야 한다! 가 조건이었습니다.

당시..(약 2주일 전인데 기억이.. 퍽퍽) 9개 정도의 컬럼이 있었고 그중 2개는 char, 1개는 int, 나머지 6개는 int2 였습니다. 모든 컬럼에는 BTREE 인덱스가 독립적으로 걸려 있었습니다. 모든 쿼리는 인덱스를 사용했구요. 테스트 전에는 항상 vacuum을 실행 했습니다.

제가 회사안에서 pgsql을 주장 했으나.. -.- 역시 DBMS는 용도에 맞춰 선택을 하는 것이.. 필요한 것은 많은 쿼리(대부분 select)를 최대한 빨리 처리하는 것이었습니다. 회원 검색DB는 물리적으로도 완전히 독립되기 때문에 사실 -_-;;;;

pgsql에 대부분 만족하지만 오직.. 속도만이 흔들리게 하는군요 -_-; 속도를 높이는 비기를 알려주세욧! 크흑

기본 mysql을 transaction을 지원하지 않기 때문에 단순한 구조에서는 빠르지 않을 수가 없습니다.

만약 pgsql의 고급 sql 기능들이 필요없다고 하고 속도가 중요한 factor라고 한다면 그리고 아주 단순한(말씀 하신 회원 정보) 구조라고 한다면 mysql이 더 적합할 것 같습니다.

사실 어떤 DB 전문가가 mysql은 DBMS가 아니라 고급 파일 시스템에 가깝다라고 평가한 것을 봤고 저도 몇가지 이유 때문에 Pgsql을 선호하지만 때로는 고급 파일 시스템이 더 적합한 곳도 있기 마련이지요. ^^

다만 말씀하신 것 처럼 모든 컬럼에 index가 걸려있다면 transactoin이 되는 pgsql은 더 부하가 많아지겠죠?

그리고 index는 독립적으로 따로 거는 것 보다는 여러 컬럼으로 구성된 index를 거는 것이 효과적입니다. 인텍스를 다 건다고 그걸 다 쓰지 않거든요. 가장 적당한 것을 골라 그놈 하나만 쓴다고 보시는 것이 맞을 듯 합니다. 좌우간 explain 한번 해보시죠.

table 구조랑 질의문을 공개하실 수 있으면 같이 연구해 볼 수 있을 듯합니다.

뭐... 알아서 잘 하셨겠지만 머리를 모으면 좀더 좋은 아이디어가 떠오를 수 있으니까..

전 단지 속도 때문에 MySql을 포기하고 PostgreSQL로 온게 아닙니다...

솔직히 INSERT는 MySql쪽이 빨랐지요...

이건 뭐 인텍스나 뭐 그런 것과는 하등 상관이 없는 문제니까요

하지만 정작 DB를 1~2년 돌리다 보니 INSERT속도는 둘째가 되고...내부적으로 통계내고 하는 면이 더 우선이 되더군요...(현재 유통회사 DB 지원중...^^;)

이런부분에 대해서라면 이미 MySQL쪽에 큰 기대 안하고 있습니다...차츰 나아질거라고 생각은 하지만 그걸 바라보고 일할수는 없으니까요...^^;

아무래도 DB마다의 특성이 있겠지요...만일 커뮤니티의 게시판 운영을 위해서라면 지금이라도 분명히 MySql 쓰겠지만

통상적인 회사업무를 위해서라면 속도에 대해선 크게 미련을 가지지 않고 PostgreSQL을 선택할 것입니다.