아, 그래요?
정말 멋진 MS-SQL 입니다. 

상용이고, 그 수많은 개발자들이 심혈을 기우려 만든 것이 그렇겠죠.

당연한 결과라고 믿고싶습니다. 

그런 멋진 놈들과 비교를 하면,
PostgreSQL 놈은 그리 멋진 놈이 못 됩니다. 

삼류들의 특징은 안되면 다른 방법으로 찾습니다. 
왜냐하면, MS-SQL이나, Oracle을 쓸만큼의 형편이 못되기 때문입니다. 

없는데서, 어떻게든 구질구질 별짓을 다 하면서 문제를 풀어가려고 하죠.
이것은 이동네에서는 삽질이라고 합디다.

그것이 별로 바람직한 모습이 아니면, 
해결책은 두가지입니다. 

1. 열심히 돈 벌어서 더 좋은 놈을 쓰든지, 
2. 이 못난 놈을 파고 들어 좋은 놈으로 내가 직접 만들어서 쓰든지.

저는 게을러서, 둘다 못하고 있습니다.

그런말을 합니다. 
DB가 못났냐? 그럼 돈 많은 돈을 벌어 더 좋은 놈으로 바꾸어라, 
그래도 뭔가 문제가 있냐? 그러면 더 돈 많이 벌어 더 좋은 장비로 바꾸어라.
그래도 뭔가 문제가 있으면, 더 돈 많이 벌어 유능한 DBA를 구하라. 
그래도 뭔가 문제가 있으면, 더 돈 많이 벌어 DB 쪽 일을 하지 마라.
참 멋진 말이죠?

이런 관점에서 PostgreSQL 쪽을 바라보면 참 쓸모 없는 놈입니다. 
보는 시각을 바꾸든가, 
아니면, 이쪽에 관심을 가지지 말든가.

-- 자료가 많을수록(그렇게 엄청나지도 않고 만개 정도만해도)차이가 엄청나더군요.
-- Ms-SQL은 그냥 반짝이는 수준인데,
-- postgresql은 답답할 정도더군요.(자료양도 Ms-SQL쪽이 열배도 더 많았는데...)

예 저도 postgresql 이 참 답답합니다.
처음에는 메뉴얼이 잘 되있다고 생각했는데 C/C++ 로 다이렉트로 제어를 할라도 보니까
메뉴얼에 빠진게 상당히 많드라구요 그래서 확장 모듈 폴더에 있는 소스를 삽질하면서
짜증나게 분석하고 있읍니다. 
이 놈의 PostgreSQL  빨리 없어져야 합니다.
그러나 PostgreSQL 이 없어질 지경이면 오픈소스도 아마 없어질 지경이 아닐까요.
그래서 PostgreSQL 은 오픈소스가 사라지는 날까지 사라지지 않았으면 좋겠읍니다.

구체적인 테이블 구조 및 데이터 입력방법을 알려주실수 있나요?

제컴에 있는 MS-SQL 2005 Express 과 PostgreSQL8.2 에서 비교한번

해보게요^^ 혹 해결책 같은것이 있는지 알아볼수 도 있지 않을런지요^^

상용 database와의 직접적인 비교는 무리가 있는게 당연한게 아닐런지요^^

이런 저런 정보들이 모여서 PostgreSQL 을 활용하는데 

도움이 된다면 그것만으로도 가치가 있는 일일듯 합니다만^^

전 다른 사용DB와 비교해도 성능이 전혀 딸리지 않던데 ㅎㅎ

오라클9 정도랑은 비교해도 성능이 뒤지지 않습니다

mysql과도 마찬가지구요..

다른 DB는 특별히 테스트를 안해봐서 모르겠네요 ㅎㅎ

저희는 최근에 비용문제때문에 ms-sql -> postgresql 로 마이그레이션 했습니다.

일 50만 페이지뷰에 대략 200개의 게시물, 게시물당 10개 정도의 코멘트가 올라오고, 
총 13만개 정도의 게시물이 쌓여있는데요
게시판 페이징도 별 다른거없이 LIMIT OFFSET을 사용했고
아직까지 미덥지 않은 Npgsql 드라이버를 사용하고 있습니다. 

페이지로딩 속도에 예민한 유저들이  아직까지 불평하는게 없는거보면 
속도는 그럭저럭 만족합니다. 


ms-sql의 BOL이나 커뮤니티에 비해 참고할 만한 레퍼런스가 부족해서 
삽질을 많이 하게 된다는거 빼고는 말이죠. 이건 뭐.. 무한 삽질이 해결해주겠죠 -_-;;

이곳 DSN도 postgresql입니다.

수십만개의 게시물과 FTI를 위해 수백만 레코드가 있는데 아래 수행시간을 보시면 될것 같습니다.

참고로 pgpool을 쓰면 아래의 수행시간을 약 절반으로도 줄일 수 있습니다.

게시판은 제목,작성자,작성일자,조회수만 조회되니까 그래도 차이가나긴하지만, 그렇게 답답할 정도는 아닌데, 필드수가 많아질수록 답답해지더라고요. 웹용으로는 그럭저럭 쓸만하겠지만, 관리항목이 많을 수밖에 없는 응용프로그램용으로는 부적합 한듯...

저도 현업에서 pgsql을 사용하는데 필드가 50개가 넘는 뷰도 많습니다.

물론 테이블 3~4개가 조인된 뷰들인데 보통 테이블당 데이터가 50~300 만건 입니다.

이런 테이블이 수십개 있습니다..

하지만 찾아와! 하면 ms 단위로 찾아옵니다.

[root@magicdb01 pgsql8]# du -hs /data/pgsql8

7.3G /data/pgsql8

autovacuum을 돌리면서도 쌓인 데이터가 이정도이고 dump하면 3기가 단위의 덤프파일이 나오고 항상 열려있는 세션이 300개 이상입니다..

솔직히 다른 DBMS들도 써보면서 이렇게 속 안썩이고 기본에 충실한놈이 없습니다;

글을 꼼꼼히 읽어보니까, data grid 테스트 같네요. ^^

그쪽 문제는 db 자체의 문제라기 보다는 

그 다음 응용프로그램과, 그 db 드라이버와의 관계가 높습니다. 

m$ 동네쪽의 동적 커서 사용에 관계되는 부분 인 것같습니다. 

이 부분에 대한 테스트는 아마 db 드라이버의 문제입니다. 

m$ 쪽은 dynamic cursor 를 쓸터이고, pg 쪽은 static cursor를 쓰기 때문일겝니다. 

정확한 테스트를 하려면, 

select * from table 의 결과를 텍스트 파일 오픈해서 그 내용을 text로 써보세요. 

그리고 그 파일을 열어서 닫는데까지 걸린 시간을 비교해야할 것같습니다. 

그런다고, m$ 동네쪽, text file exporting API를 쓰고, 

pg쪽에서는 그냥 getValue() API를 쓰고 하면서 비교하시면 안되시고요. 

만일 그런게 있다면 말입니다.

단지, data grid나, 웹에서 next 페이지가 있는 그런 방식으로 비교하면 안될 것같네요.

참고로, PostgreSQL ODBC 쪽 개발은 아마도 수해전에 개발이 중지 되어있습니다. 

그 당시 개발자들의 능력부족으로 꽤나 미흡한 ODBC를 아직도 쓰고 있는 상황입니다. 

(문제는 그 당시 ODBC 개발할 당시 서버가 dynamic cursor 관련을 서버 차원에서 지원하질 못했습니다. 그러니, odbc 쪽에서도 그 문제를 그대로 안고 있겠죠.)

현재 win32 쪽 관심있는 사람들은 dotnet 드라이버를 열심히 만들고는 있는데, 

과연 그들이 만들어내는 드라이버 모습이 m$ 동네쪽에서 만들어내는 놈과 

비슷할지는 의문입니다. 별로 관심을 안 가져봐서.

ms-sql은 쿼리분석기로, pgsql은 pgAdminIII Query로(윈도버전) 테스트했습니다.

물론 ms-sql은대충 하고, pgsql은 많은 시간을 투자해서 튜닝해놓으면

비슷하게 나올수는 있겠죠.

하지만 같은 조건이라면 차이가 많이 나는것 같습니다.

전엔 별 생각없이 설계해도 항의 받을 정도는 아녔었는데,

DB바꾸면서 시작부터 항의에 진땀입니다. T.T;

소량데이타로 로컬서 테스트할땐 못느꼈는데, 실무투입시키고, 일주일도 안돼서

이렇습니다. 전엔 똑같은 구조로 2~3년 써도 늦단말 한마디 못들었습니다. ㅡ,ㅡ;

같은 구조 같은 업무이고, 도움까지 받아서 튜닝해도 전에 무지한 머리서 나온 Ms시절 쿼리보다 너무 느립니다. 흑.

그럼 더 확실하네요. ^^

응용 프로그램 차원의 cursor 문제입니다. 

db가 느린게 아니라, cursor 처리 방식의 차이입니다. 

m$-sql 쪽에서는 응용프로그램을 select * from table ... 형태로 움직일때, 아마 기본적으로 동적 커서를 쓰나봅니다. 

pg 쪽은 특별하게 지정하지 않으면 static을 씁니다. 
문제는 win32 응용 프로그램에서 동적 커서를 사용하는 방식으로 data grid를 만드려면 
무한한 삽질이 필요합니다. 

이부분은 db를 튜닝한다고 해서 해결날 문제가 아닙니다.

그냥 단순하게, ms-sql 쓰시고 고객에게 db 비용까지 받으세요.

흑, 허탈하군요.

처음에 시작할때, ODBC설치 안하고 배포하는문제 때문에 여러밤을 샜었는데...

그거 해결하니, 또다른 더큰 문제가...

ms-sql은 유저단위로 돈을 받아서... T.T; 요즘 사람들이 돈좀 들어간다하면 아예 엑셀로대충 하고만다는 식이니 이거참...

지금까지 근무했던 곳은 개발업체에서도 해적판을 쓰긴 하지만, 혹시나 단속에 걸리기라도 하면.. -0-;;;

가뜩이나 영업하기 힘든데, 참 어렵군요.

감사합니다.

Mysql도 마찬가지겠지만, 혹시나 하는 맘으로 테스트함 해봐야겠군요.

이기자님

PostgreSQL 을 리눅스등 유닉스 계열에 설치하시고 동일한 데이타 입력후 테스트 해보시면 어떨런지요?

저역시 Postgresql 을 사용하며,

어려운(;;;;) 트리거등은 만들어 쓰지 않고 좀 무식하게 우격다짐(!)  필드를 가진 테이블등을 만들어 사용하고 있습니다만.

성능(속도)면에서  실망을 해본적은 없었습니다.

오픈소스 솔루션에서 상용 솔루션에 없는 옵티마이징 부분은 사용자의 몫이 아닐까 합니다.

ㅋㅋㅋ

옛날에 다투던 문제들이 아직도 문제거리가 되는군요.

나름대로의 영역이 있습니다.

성능면에서 PostgreSQL 은 상용디비에 비해서 많이 뒤진다는 생각은 하지 않습니다.
어떻게 사용자가 optimization 을 해 내고, 어떻게 DB 모델링을 하느냐가 더 문제겠지요.
한마디로 사용자의 책임이 상용 DBMS 보다는 PostgreSQL 쪽이 훨씬 크다는 이야기입니다.


그리고 최대의 단점...
Warranty 를 지원해주지 않는다는 것입니다.
회사에서 설치를 해서 쓸려고 하는데 어느 관리자가 PostgreSQL 을 사용할려고 할까요.
문제되면 돈으로도 해결이 안됩니다.
스스로 다 해결해야죠.
그런데 사용 DBMS 는 최악의 경우 돈으로 해결이 됩니다.
안되면 회사에 할말이라도 있죠.
돈주고 M$ 놈들 시켰는데도 불구하고 해결을 못해 주더라.
그럼 회사측에서 이와 관련하여 직원의 책임은 묻지 않겠죠.
하지만 본인이 우겨서 PostgreSQL 을 설치한 경우를 가정해 봅시다.
혼자 뺑이쳐서 해결 못해서 회사에 보고하면... 야... 너가 우겨서 설치했는데 이것도 해결못하면 어쩌냐.

회사 비용 생각해 주다가 덤탱이 쓰는 꼴이죠.

하지만 개인이 사용하는 경우를 생각해 봅시다.
불법소프트웨어를 사용하는 경우가 아니라면 5라이센스에 수백만원이 들어가는 M$SQL 을 집에서 사용하십니까?
저는 돈이 그리 안 많아서 그리 못합니다.
이곳 DSN 도 부자 동네가 아니라서 그렇게 오라클, MS-SQL 사용할 입장이 못됩니다.
돈안들이고 최소한의 비용으로 최대한의 효과를 내려다 보니 할수 없이 PostgreSQL 을 선택했던 것이죠. ^^

여하튼 그렇습니다.

고민하지 마시고 여러가지 두루 두루 섭렵해 보세요 ^^

글의 내용을 봐서는 MS-SQL 과 PostgreSQL 모두 Windows 환경에서 테스트한 것인지 아니면 똑같은 기계 두대를 가지고 하나는 Windows를 설치해서 MS-SQL로 테스트하고 다른 하나는 Linux나 다른 유닉스를 설치한 다음 PostgreSQL을 테스트한 것인지 잘 구분이 안되네요.

둘다 Windows에서 테스트했다면 MS-SQL이 더 잘 나올거라는 건 하나마나한 얘기일듯 하고요,
똑같은 기계 두대를 가지고 Windows + MS-SQL 및 Unix + PostgreSQL의 조합이었다면 그리 속도차이가 날것 같지는 않아보입니다.

정확한 테스트 환경을 알려주시면 다른 분들에게도 도움이 될것 같군요.

아 테스트 하신분은 윈도우에 postgresql을 설치하신 거예요

8.1.x인데 아직 윈도우에서는 예쁘게 돌아가지 않네요 ㅎㅎ

결국 MS-SQL 과 PostgreSQL for Win32를 비교했다는 말인데, 기대가 너무 컸던 모양이네요. ^^;

PostgreSQL은 유닉스 계열에 최적화 되어 있습니다. Windows 에 포팅된건 버전 8.x 대 부터인데 이제 겨우 마이너버전이 두번 업데이트 된 정도이니 너무 큰 기대를 하시는건 좀 무리가 있지요.

PostgreSQL을 쓰시려면 유닉스에 컴파일하여 사용하기를 권장합니다.

올만에 와서 좋은 글들 잘 읽었습니다.

그런데 하나만 덧붙이면 ms sql의 경우 디폴트 셋팅으로도 어느 정도 성능이 나지만 pgsql의 경우는 상당히 보수적으로 설정이 되어 있어서 시스템에 맞춰서 설정을 바꿔야 성능이 나아지는 것 같더군요.

그리고 소트가 필요 없는 SELECT 문인데 컬럼 숫자에 따라서 속도가 느려진다면 드라이버의 문제를 생각해봐야 할 것 같습니다. DB 입장에서는 소트 때문에 메모리에 담아두어야 할 경우가 아니라면 컬럼 숫자가 성능에 영향을 줄 요소가 거의 없으니까요.