PostgreSQL(포스트그레스·큐·엘)에 대해 자주 있는 질문과 그 해답(FAQ)
원문 최종 갱신일: Sun Oct 13 23:15:09 EDT 2002
현재의 유지 관리자: Bruce Momjian (pgman@candle.pha.pa.us)
Maintainer of Japanese Translation: Jun Kuwamura (juk@PostgreSQL.jp)
이 문서의 최신판은 http://www.PostgreSQL.org/docs/faq-english.html 로 보는 것이
할 수 있습니다.
플랫폼에 특유의 질문에 대해서는: http://www.PostgreSQL.org/users-lounge/
docs/faq.html
에 회답이 있습니다.
(이하, 역자에 의한 주석을 [역주： 와 ] 로 둘러싸고 적습니다. )
[역주：
일본어판 제작에 대한 메모는 최후미에 이동했습니다.
일본어판의 이 문서는 본가 "User's Lounge" 의 "Collection of FAQs" 의
"Japanese" 라고 하는 표제의 곳에 있습니다. 또, 이하의 사이트에도
있습니다.
http://www.PostgreSQL.jp/subcommittee/jpugdoc/
http://www.rccm.co.jp/~juk/pgsql/
http://www.linux.or.jp/JF/
이 일역에 대해 문의사항은(juk@PostgreSQL.jp)까지 메일로 주세요.
2002년 10월 16일 쿠와무라 윤
]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
일반적인 질문
1.1) PostgreSQL란 무엇입니까? 뭐라고 읽습니까?
1.2) PostgreSQL의 저작권은 어떻게 되어 있습니까?
1.3) PostgreSQL의 동작하는 Unix 플랫폼은?
1.4) Unix 이외의 이식판으로 사용할 수 있는 것은?
1.5) PostgreSQL는 어디에서 입수할 수 있습니까?
1.6) 지원는 어디서 받게 됩니까?
1.7) 최신판은 어떤 것입니까
1.8) 어떠한 문서가 있습니까?
1.9) 기존의 버그나 아직도 없는 기능은 어떻게 찾아냅니까?
1.10) SQL는 어떻게 하면 배울 수 있습니까?
1.11) PostgreSQL는 서기 2000년 문제(Y2K)에 대응하고 있습니까?
1.12) 개발 팀에는 어떻게 참가합니까?
1.13) 버그 리포트는 어떻게 발신합니까?
1.14) 다른 DBMS의 것과 비교해 PostgreSQL는 어떻게인 것입니다인가?
1.15) PostgreSQL를 자금면에서 원조하려면 어떻게 하면 좋습니까?
유저·클라이언트의 질문
2.1) PostgreSQL 의 ODBC 드라이버는 있습니까?
2.2) PostgreSQL 를 Web 페이지와 제휴시키려면 어떤 툴이 있습니까?
2.3) PostgreSQL 에 그래피컬·유저 인터페이스는 있습니까? 레포트지
네레이타나 묻어 문의 언어 인터페이스는 있습니까?
2.4) 어떠한 언어로 PostgreSQL 와 통신으로 인가?
관리상의 질문
3.1) 어떻게 하면 /usr/local/pgsql 이외의 장소에 인스톨 할 수 있습니까?
3.2) postmaster 를 달리게 하면(자), Bad System Call 라든지 코어·덤프 했다는 메신져
지가 나옵니다. 왜입니까?
3.3) postmaster 를 달리게 하려고 하면(자), IpcMemoryCreate 에러가 나옵니다. 왜입니다
인가?
3.4) postmaster를 달리게 하려고 하면(자), IpcSemaphoreCreate 에러가 나옵니다. 왜로
인가?
3.5) 다른 호스트로부터의 접속은 어떻게 제어합니까?
3.6) 보다 좋은 성능을 얻기 위해서(때문에)는, 데이타베이스·엔진을 어떻게 조정하면 양
있고입니까?
3.7) 어떠한 데바그 기능을 사용할 수 있습니까?
3.8) 접속하려고 할 때 'Sorry, too many clients'가 나오는 것은 왜입니까?
3.9) pgsql_tmp 디렉토리안에는 무엇이 있습니까?
3.10) PostgreSQL의 메이저 릴리즈를 업데이트 하는데 덤프와 restore를 하는거야
구라고는 안 되는 것은 왜입니까?
조작상의 질문
4.1) 바이너리·커서와 통상 커서와의 차이는 무엇입니까?
4.2) 최초의 수로우만을 select 하려면 어떻게 합니까?
4.3) 테이블이나 그 외의 정보의 리스트를 psql 로 보려면 어떻게 합니까?
4.4) 테이블에서 컬럼의 삭제는 어떻게 합니까?
4.5) 로우, 테이블, 데이타베이스의 최대 사이즈는?
4.6) 일반적인 텍스트 파일로부터 데이터를 보존하려면 , 데이타베이스의 디스크용
양은 어느 정도 필요합니까?
4.7) 정의된 테이블, 인덱스, 데이타베이스, 및, 유저를 어떻게
해 찾아냅니까?
4.8) 문의가 늦은 데다가, 인덱스를 사용하고 있는 모습이 없습니다. 왜입니까
?
4.9) 문의 오브티마이자가 어떻게 문의를 평가할까를 보려면 끼리
인가?
4.10) R-tree 인덱스란 무엇입니까?
4.11) 유전적 문의 최적화란 무엇입니까?
4.12) 정규 표현에서의 검색이나 대문자와 소문자를 구별하지 않는 정규 표현 검색은 어떻게 열매
나타냅니까? 대문자와 소문자를 구별하지 않는 검색을 위한 인덱스는 어떻게 사
있습니까?
4.13) 문의 중(안)에서, 필드가 NULL 인 것을 검출하려면 어떻게 합니까
?
4.14) 다양한 캐릭터형의 각각의 차이는 무엇입니까?
4.15. 1) 통번(serial)/자동 증분 필드는 어떻게 만듭니까?
4.15. 2) SERIAL 데이터형에 삽입되는 값은, 어떻게 하면 얻을 수 있습니까?
4.15. 3) 다른 유저와의 경합 상태를 피하기 위해서(때문에)는, currval()와 nextval()는 사용하는거야
있고 편이 좋은 것일까요?
4.15. 4) 트랜잭션(transaction)가 중단했을 때에 이제 한 번 순차 순서 번호가 사용되지 않는거야
(은)는 왜입니까? 순차 순서/SERIAL 컬럼에 빈 곳이 있는 것은 왜입니까?
4.16) OID 란 무엇입니까? TID 란 무엇입니까?
4.17) PostgreSQL 로 사용되는 몇개의 용어의 의미는 무엇입니까?
4.18) 에러 메세지 "ERROR: Memory exhausted in AllocSetAlloc()"가 나오는 것은
입니까?
4.19) 어느 버젼의 PostgreSQL 를 달리게 하고 있는지를 조사하려면 어떻게 합니까?
4.20) 라지 오브젝트의 조작으로, invalid large obj descriptor와 나오는 것은 왜로
인가?
4.21) 현재의 시각이 디폴트가 되는 것 같은 컬럼은 어떻게 만듭니까?
4.22) 왜, IN를 사용하는 부문의가 매우 늦습니까?
4.23) 외부 결합(outer join)은 어떻게 실현됩니까?
4.24) 복수의 데이타베이스를 사용하는 문의는 어떻게 하면 할 수 있습니까?
4.25) 함수로 복수의 로우 또는 컬럼을 돌려주려면 어떻게 합니까?
4.26) 왜, PL/PgSQL 함수중에서 일시 테이블을 확실히 create/drop 하는 것이로
기내의 것입니까?
4.27) 어떠한 리프리케이션오프션을 이용할 수 있습니까?
4.28) 어떠한 암호화 옵션을 이용할 수 있습니까?
PostgreSQL의 확장에 대한 질문
5.1) 스스로 쓴 유저 정의 함수를 psql 중(안)에서 실행하면(자) 코어·덤프 해 버려
(은)는 왜입니까?
5.2) PostgreSQL 용으로 쓴 조금 멋진 새로운 형태나 함수를 제공해 프로젝트에
공헌하고 싶습니다만?
5.3) 타풀을 돌려주는 C언어의 함수는 어떻게 씁니까?
5.4) 소스·파일을 변경했습니다. 재컴파일 해도 변화를 볼 수 없는 것은 왜
입니까?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
일반적인 질문
1.1) PostgreSQL 란 무엇입니까? 뭐라고 읽습니까?
Post-Gres-Q-L. (포스트 - 그레스 - 큐 - 엘 )(이)라고 발음합니다.
PostgreSQL 는 차세대 DBMS 연구용의 prototype인 POSTGRES 데이타베이스 관리
시스템의 개량판입니다. PostgreSQL 는 POSTGRES 의 강력한 데이터·모델과 풍부한 데이
타·타입(형태)을 보관 유지하면서, POSTGRES 로 사용된 PostQuel 문의 언어를, 확
장 한 SQL 의 부분집합에 옮겨놓고 있습니다. PostgreSQL 는 무료로 완전한 소스를 이익
용무 할 수 있습니다.
PostgreSQL 의 개발은, PostgreSQL 개발 메일링리스트에 참가하고 있는 개발자들의 치
무로 모두 행해지고 있습니다. 현재의 단장은 Marc G. Fournier (
scrappy@PostgreSQL.org )입니다. (아래와 같은 1.6절에 참가의 방법이 있습니다. ) 현재, 이 치
무가 PostgreSQL 개발의 모든 보살펴 주고 있습니다.
Postgres95-1. 01 의 중심적인 개발자는 Andrew Yu 와 Jolly Chen 였지만, 그 외 여럿
의 사람들이 이 코드의 이식, 테스트, 데바그, 및, 개량에 참가했습니다.
PostgreSQL 의 파생원코드인 POSTGRES 는 캘리포니아 대학 버크 레이교냄새
(이)라고, Michael Stonebraker 교수의 지휘 아래, 많은 학생, 졸업생, 본직의 프로그래머
들의 노력에 의해 만들어졌습니다.
버크 레이에 있어서의 이 소프트웨어의 원래의 이름은 Postgres 였지만, SQL 의 기능
하지만 추가된 1995 년에 그 이름은 Postgres95 로 변경되어 1996 년의 끝에 그 이름
(은)는 PostgreSQL 로 변경되었습니다.
1.2) PostgreSQL 의 저작권은 어떻게 되어 있습니까?
PostgreSQL 는 아래와 같은 저작권에 따릅니다.
[역주：
정문은 영어입니다. 참고로서 번역문을 병기 게재합니다.
]
PostgreSQL Data Base Management System
Portions Copyright (c) 1996-2002, PostgreSQL Global Development Group Portions
Copyright (c) 1994-6 Regents of the University of California
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose, without fee, and without a written agreement is
hereby granted, provided that the above copyright notice and this paragraph and
the following two paragraphs appear in all copies.
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR
DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST
PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF
THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND
THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE,
SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
POSTGRESQL 데이타베이스 관리 시스템
부분적 저작권 (c) 1996-2002, PostgreSQL 국제 개발 팀
부분적 저작권 (c) 1994-6 캘리포니아 대학 본교
본소프트웨어 및 그 문서 일식은 상기의 저작권 표시와 이 문장
및 이것에 계속되는 두 개의 단락이 모든 복제에 첨부되고 있는 한 냄새
(이)라고, 사용, 복제, 수정 및 배부의 허가를, 어떠한 목적으로 도, 무
상으로 한편 동의서 없이 행할 수 있는 것을 여기로 인정합니다.
캘리포니아 대학은, 어떠한 당사자에 대해도, 이익의 괴실을
포함한, 직접적, 간접적, 특별, 우연히 혹은 필연적에 관계없이 생겼다
손해에 대해, 비록 캘리포니아 대학이 이러한 손해에 대해 소추
(을)를 받고 있었다고 해도, 일절의 책임을 지지 않습니다.
캘리포니아 대학은, 상용 목적에 있어서의 암묵의 프로텍션과 특정 목적으로
의 적합성에 관해서는 원래, 이것들에 한정하지 않고, 어떠한 프로텍션도 방폐
것을 명언합니다. 이하에 준비된 소프트웨어는 「그대로」를
기본 원리로 해, 캘리포니아 대학은 그것을 유지, 지원, 갱신, 개량아
있고는 수정할 의무를 지지 않습니다.
[역주：
저작권에 관한 정문은 상기의 영어에 의한 표기입니다. 일본어 번역은 어디까지나
참고입니다.
]
상기는 BSD 라이센스로 고 나무 open source의 라이센스입니다. 원시 코드가 어느듯
에 사용되어도 제한하지 않습니다. 바람직한 일이므로, 우리도 그것을 바꿀 생각은
선.
1.3) PostgreSQL 의 동작환경은?
일반적으로, 최근의 Unix 호환 플랫폼이라면 PostgreSQL를 젓가락등 다투어질 것입니다
. 릴리즈의 시점에서 실제로 테스트를 행한 것의 보고가 이루어진 플랫폼에 개
있어 인스톨 안내서에 열거되어 있습니다.
1.4) Unix 이외의 이식판으로 사용할 수 있는 것은?
클라이언트
MS Windows 플랫폼상에서 주 다투기 위해서(때문에), libpq C 프로그램 라이브러리, psql, 그 외의 이
타페스, 및, 클라이언트 어플리케이션을 컴파일 하는 것은 가능
입니다. 이 경우, 클라이언트를 MS Windows 상에서 달리게 해, TCP/IP 경유로 지원함
라고 있는 Unix 플랫폼상에서 달리는 서버와 통신합니다.
Win32 libpq 프로그램 라이브러리와 psql 를 만들기 위해서(때문에), win32.mak 가 배포에 포함되어 있습니다.
PostgreSQL는 ODBC 클라이언트와도 통신할 수 있습니다.
서버
현재, Cygnus Unix/NT 이식 프로그램 라이브러리의 Cygwin 를 사용해, PostgreSQL 데이타베이스
서버는 Windows NT 와 Win2k 상에서 가동하고 있습니다. 배포에 포함되는 pgsql/doc/
FAQ_MSWIN, 혹은, http://www.PostgreSQL.org/docs/faq-mswin.html에 있는 MS
Windows FAQ 를 봐 주세요.
MS Win NT/2000/XP 네이티브판에의 이식이 현재 진행중입니다.
[역주：
Win32 네이티브판(Win32 Native version)
Windows-Native 서버 & 클라이언트 패키지가 사이토씨에 의해
유지 관리되고 있습니다.
http://hp.vector.co.jp/authors/VA023283/PostgreSQL.html
(Windows-Native Server&Client Package for PostgreSQL by Hiroshi Saito)
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html
]
1.5) PostgreSQL 는 어디에서 입수할 수 있습니까?
PostgreSQL 의 오모토의 anonymous ftp 사이트는 ftp://ftp.PostgreSQL.org/pub/ 입니다.
미러 사이트에 대해서는, 우리의 메인 Web 페이지를 봐 주세요.
[역주:
이하는 일본의 미러 사이트입니다:
Japan: ftp://mirror.nucba.ac.jp/mirror/PostgreSQL/pub/
Japan: ftp://ring.ip-kyoto.ad.jp/pub/misc/db/PostgreSQL/
Japan: ftp://ring.crl.go.jp/pub/misc/db/PostgreSQL/
Japan: ftp://ring.saitama-u.ac.jp/pub/misc/db/PostgreSQL/
Japan: ftp://ring.astem.or.jp/pub/misc/db/PostgreSQL/
Japan: ftp://ring.exp.fujixerox.co.jp/pub/misc/db/PostgreSQL/
Japan: ftp://ring.jah.ne.jp/pub/misc/db/PostgreSQL/
Japan: ftp://ring.etl.go.jp.jp/pub/misc/db/PostgreSQL/
Japan: ftp://ring.asahi-net.or.jp/pub/misc/db/PostgreSQL/
Japan: ftp://ring.so-net.ne.jp/pub/misc/db/PostgreSQL/
Japan: ftp://ring.aist.go.jp/pub/misc/db/PostgreSQL/
]
1.6) 지원는 어디서 받게 됩니까?
주요한 메일링·리스트는: pgsql-general@PostgreSQL.org입니다. PostgreSQL 에 관
것이면 논의를 할 수 있습니다. 이 리스트에의 참가의 것은, 전자 메일의 본문(Subject
행이 아닙니다)에 다음의 2행을 써,
subscribe
end
pgsql-general-request@PostgreSQL.org 에 보내 주세요.
다이제스트판의 메일링·리스트도 있습니다. 이 리스트에의 참가는 "본문"에：
subscribe
end
(이)라고 써 pgsql-general-digest-request@PostgreSQL.org 에 전자 메일을 보내 주세요
.
다이제스트판은, 메인 리스트로 수신하는 메세지가 30k 정도 쌓일 때마다 다이제스
트판 리스트의 멤버에게 송부됩니다.
버그 리포트용의 메일링리스트도 있습니다. 이 리스트에의 참가는 "본문"물어 해
에： bugs-request@PostgreSQL.org 에 전자 메일을 보내 주세요.
개발자의 논의를 위한 메일링리스트도 이용할 수 있습니다. 이 리스트에의 참가는 전자 메
르의 본문에：
subscribe
end
(이)라고 써, pgsql-hackers-request@PostgreSQL.org에 전자 메일을 보내 주세요.
http://www.PostgreSQL.org
EFNet 에 #PostgreSQL 라고 하는 IRC 채널도 있습니다. UNIX 커멘드로 irc -c '#
PostgreSQL' "$USER" irc.phoenix.net 를 사용합니다.
[역주:
1999년 7월 23일, 일본 PostgreSQL 유저회(와 -자리― 보람), 약칭 JPUG가 설립되었습니다.
JPUG 는 비영리 조직에서, PostgreSQL를 이용하는 사람들의 상호 협력의 장소입니다.
정회원의 회비는 무료입니다만, 협찬 회원의 회비와 회원의 적극적인 공헌이 회의 운영을 돕고 있습니다.
자세하게는, JPUG 의 Web 사이트:
http://www.PostgreSQL.jp/
(을)를 봐 주세요. 회원 등록도 가능해지고 있습니다.
1990년대 중순보다, 포스트그레스의 일본어 메일링·리스트를 이시이 타츠오씨가 주최하고 있습니다. 자세한 것은,
http://www.sra.co.jp/people/t-ishii/PostgreSQL/ML/info.html
(을)를 봐 주세요. 어카이브(archive)를, 원송곳씨의 pgsql-jp ML검색 시스템
http://datula.mio.org/~iwakiri/pgsql_jp/
그리고 검색할 수도 있습니다.
]
상용 지원 회사의 리스트는 http://www.PostgreSQL.org/users-lounge/
commercial-support.html에 있습니다.
[역주:
일본에서는, SRA Inc. 오픈 시스템 사업부에서 상용 지원가 행해지고 있습니다.
미러클·리눅스 주식회사에서 "Miracle Linux for PostgreSQL" 의 판매와 지원가
개시되었습니다.
]
1.7) 최신판은 어떤 것입니까
PostgreSQL 의 최신판은 버젼 7.2. 3 입니다.
우리는, 4개월마다 메이저 릴리즈를 행하는 것을 계획하고 있습니다.
1.8) 어떠한 문서가 있습니까?
배부안에, 몇개의 메뉴얼과 온라인·메뉴얼(메뉴얼·페이지)
불러 몇개의 작은 테스트 예제가 포함됩니다. /doc 디렉토리를 봐 주세요. 또
, 메뉴얼은, http://www.PostgreSQL.org/users-lounge/docs/ 로 온라인에서도
열람할 수 있습니다.
[역주:
(주) SRA와 일본 포스트그레스유자회에서 번역되어
「PostgreSQL 오피셜 메뉴얼」
(으)로서 출판되고 있습니다.
]
온라인으로 참조할 수 있는 PostgreSQL 의 책도 2권 있습니다. http://www.PostgreSQL.org/
docs/awbook.html
[역주:
일본 포스트그레스유자회의 「PostgreSQL Book 번역 분과회」
에서 번역되었습니다.
]
및, http://www.commandprompt.com/ppbook/ 입니다. 구입 가능한 서적의 목록은,
http://www.jp.PostgreSQL.org/books/ 에 있습니다. PostgreSQL 기술 정보 기사도,
http://techdocs.PostgreSQL.org/ 에 있습니다.
[역주: 일역 문서는, 일본 포스트그레스유자회의 http://www.postgresql.jp/
document/ 를 봐 주세요. ]
psql 도, 형태, 연산자, 함수, 집약, 그 외의 정보를 보여드리는, 몇개의 훌륭하다
\d 커멘드를 가집니다.
우리의 Web 사이트에는, 좀 더 많은 문서가 있습니다.
1.9) 기존의 버그나 아직도 없는 기능은 어떻게 찾아냅니까?
PostgreSQL는 확장된 SQL-92의 부분집합을 지원합니다. 우리의 페이지의 TODO
리스트에, 기존의 버그나 결핍 기능이나 장래 계획에 대한 기술이 있습니다.
1.10) SQL 는 어떻게 하면 배울 수 있습니까?
http://www.PostgreSQL.org/docs/awbook.html 에 있는 PostgreSQL책으로 SQL 를 가르치고 있고
.
[역주:
일본 포스트그레스유자회의 「PostgreSQL Book 번역 분과회」
에서 번역되고 출판되고 있습니다.
]
그 외에도 PostgreSQL책으로서 http://www.commandprompt.com/ppbook 가 있습니다.
훌륭한 안내서는, http://www.intermedia.net/support/sql/sqltut.shtm, http://
ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM, 그리고, http://
sqlcourse.com 에 있습니다.
그 외에서는, "Teach Yourself SQL in 21 Days, Second Edition" 가 http://
members.tripod.com/er4ebus/sql/index.htm에 있습니다.
많은 유저에게, The Practical SQL Handbook, Bowman Judith S. et al.,
Addison-Wesley 가 호평입니다. 그 외에, The Complete Reference SQL, Groff et al.,
McGraw-Hill 와 같은의도 있습니다.
[역주:
이시이 타츠오씨에 의한 일본어의 참고 문헌의 소개 페이지
http://www.SRA.co.jp/people/t-ishii/PostgreSQL/doc-jp/index.html
(이)가 있습니다.
콘도직문씨의 「초심자향의 DB설계 입문·SQL 입문 참고서 소개」의 코너
http://www.shonan.ne.jp/~nkon/ipsql/books_SQL.html
(이)가 있습니다.
홋타 린영씨의 「PostgreSQL 일본어 메뉴얼」
http://www.net-newbie.com/
그럼 온라인 메뉴얼의 검색을 할 수 있습니다.
마루야마 불이부씨의 UNIX 데이타베이스 입문
http://www.wakhok.ac.jp/DB/DB.html
도 온라인으로 읽을 수가 있습니다.
]
1.11) PostgreSQL는 서기 2000년 문제(Y2K)에 대응하고 있습니까?
대응하고 있습니다. 서기 2000년부터 후의 일자도, 기원 전 2000년부터 전날부도, 간단하게 취급해라
.
1.12) 개발 팀에는 어떻게 참가합니까?
우선 최초(1번째 )에, 최신의 소스를 다운로드해, 우리의 Web 사이트나 배포에 함
라고 있는 PostgreSQL Developers의 문서를 읽습니다. 2번째에, pgsql-hackers 와
pgsql-patches 메일링·리스트를 구독(subscribe)합니다. 3번째에, 고품질의 팍
치를 pgsql-patches에 발신합니다.
대략 열 명 조금의 사람들이, PostgreSQL CVS 어카이브(archive)에 위탁하는 권한을 가져
있습니다. 그 각각의 사람들이 많은 고품질인 패치를 발신하므로, 현재 코밋타
되고 있는 사람들은 거기에 따라붙는 것이 큰 일입니다만, 우리는 그들이 위탁한 패치
(은)는 고품질이다고 확신하고 있습니다.
1.13) 버그 리포트는 어떻게 발신합니까?
http://www.PostgreSQL.org/bugs/bugs.phpPostgreSQL BugTool (버그 툴)의 페이지
(을)를 방문해 봐 주세요. 버그 리포트를 제출하는 방법에 대한 안내와 지침이 있습니다.
그 전에 http://PostgreSQL.org에 있는 최신의 FAQ 를 체크해 주세요.
그것과 동시에 ftp 사이트 ftp://ftp.PostgreSQL.org/pub/로, 좀 더 새로운 버젼
의 PostgreSQL 혹은 패치를 찾아 봐 주세요.
1.14) 다른 DBMS의 것과 비교해 PostgreSQL는 어떻게인 것입니다인가?
소프트웨어를 재는 방법에는 몇개인가 있습니다. 기능과 성능과 신뢰성과 지원와 가격
입니다.
기능(Features)
PostgreSQL는, 트랜잭션(transaction), 부문의해 트리거, 뷰, 외부 키정
궁합 참조, 및, 세련된 락 기구 등, 대규모 상용 DBMS가 가지는 기능와
가지고 있습니다. 한층 더 PostgreSQL는, 유저 정의형, 계승, 룰, 그리고
, 락 경합을 축소하는 멀티 버젼 동시성 제어 등, 상용 DBMS도 소지
없는 것 같은 기능을 몇개인가 가지고 있습니다.
성능(Performance)
PostgreSQL는 다른 상용 혹은 open source의 데이타베이스와 호각의 성능도 가져
. 어느 면에서는 보다 빠르기도 하고, 다른 면에서는 보다 늦거나 합니다. MySQL 등
의 특화형 데이타베이스·시스템에 비해서, PostgreSQL의 삽입/갱신이 늦은 것은
, 트랜잭션(transaction)에 의한 오버헤드가 있기 때문입니다. 물론, MySQL에는 위
기의 Features의 마디에 나타내는 것 같은 기능은 전혀 없습니다. 우리는, PostgreSQL에
유연성과 기능성을 짜넣으면서도, 끊임없이, 프로 filer-에 걸거나 소스코
드를 해석하거나 해, 성능의 개선을 계속하고 있습니다. PostgreSQL 와 MySQL 를 비
교 하고 있는 재미있는 Web 페이지가 http://openacs.org/why-not-mysql.html에
.
PostgreSQL는, Unix 프로세스를 기동하는 것으로써 유저 접속을 조작합니다. 복
수의 연구 최종 단계·프로세스가 정보를 잠그면서 데이터·버퍼를 공유해
. 멀티 CPU에서는, 간단하게 복수의 연구 최종 단계를 각각의 CPU로 달리게 하는 것
하지만 할 수 있습니다.
신뢰성(Reliability)
우리는, DBMS의 신뢰성이 높지 않으면 그 가치가 없는 일을 이해하고 있습니다. 충분히 테
파업 해, 안정된 코드를 버그를 최소로 하고 나서 릴리즈 하도록(듯이) 근무하고 있습니다
. 각각의 릴리즈는 적어도 1개월 이상의 베타·테스트를 행해, 지금까지
의 릴리즈의 히스토리가, 제품판으로서 안정된 견고한 릴리즈인 것을 이야기해
있습니다. 이 분야에서는, 다른 데이타베이스와 비교해도 손색이 없는 것에 자신을 지
(이)라고 있습니다.
지원(Support)
우리의 메일링리스트는, 조우하는 어떠한 문제에 대해서도 해결에의 도움을 주어
(이)라고 주는, 개발자나 유저의 큰 모임에의 접점을 제공하고 있습니다. 우리는 문제
의 해결을 프로텍션할 수 없습니다만, 상용 데이타베이스여도 항상 해결되고
(뜻)이유가 아닙니다. 개발자나, 유저·커뮤니티, 메뉴얼류, 거기에
, 원시 코드등에 직접 액세스 할 수 있는 것 따라, PostgreSQL의 지원는,
다른 DBMS 지원보다 뛰어난 것이 되고 있습니다. 요망에 대답해, 일 마다의 상
용지원 등도 있습니다(FAQ1. 6절을 봐 주세요).
가격(Price)
PostgreSQL의 이용은, 상용에서도 비상용에서도, 모두 무료입니다. 상기에 나타내 있는 BSD
스타일의 사용 허락에 빗나가지 않는 이상 PostgreSQL의 코드를 제한 없음으로 상품에 짜
붐빌 수가 있습니다.
1.15) PostgreSQL를 자금면에서 원조하려면 어떻게 하면 좋습니까?
PostgreSQL는, 우리가 시작한 1996년 이래, 최고 클래스의 정보 기반을 가지고 있습니다. 이것
(은)는 모두, Marc Fournie씨 덕분에, 그는 이 기반을 몇년에 걸쳐 창조해 관리
해 왔습니다.
질이 좋은 기반은 open source·프로젝트에 있어서는 매우 중요한 것으로, 전진
기세를 잃는 프로젝트의 분열을 회피합니다.
물론, 이 기반은 싼 것으로는 없습니다. 계속 하기 위해서(때문에) 는 매월 혹은 1
때의 경비가 듭니다. 만약, 당신이나 당신의 회사에, 이러한 노력을 위한 자금을
돕기 위해서(때문에) 베풀 수가 있는 것 같다면, https://store.pgsql.com/shopping/로부터
기부를 부탁합니다.
또, Web 페이지에는 PostgreSQL, Inc 와 있습니다만, 거기의"의원(contributions)"아
이템은 PostgreSQL 프로젝트를 지원하기 위해(때문에)만의 유익으로, 결코 특정의 회
회사를 위한 자금 (위해)때문에가 아닙니다. 만약, 어음(check)이 형편이 좋다면 연락처
의 주소에 전송해 주세요.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
유저·클라이언트의 질문
2.1) PostgreSQL 를 위한 ODBC 드라이버는 있습니까?
PsqlODBC 와 OpenLink ODBC 의 두 개의 ODBC 드라이버가 이용 가능합니다.
PsqlODBC 는 PostgreSQL 의 배포에 포함되어 있습니다. 거기에 붙은 게다가 상세한 정보는
ftp://ftp.PostgreSQL.org/pub/odbc/ 로부터 취득할 수 있습니다.
[역주:
PsqlODBC 의 일본어 패치를 카타오카 유타카생씨(kataoka@interwiz.koganei.tokyo.jp)가 만들어졌습니다:
●http://www.interwiz.koganei.tokyo.jp/software/PsqlODBC/index.html
현재, 최신판은 이노우에 히로시씨의 사이트에 있습니다.
●http://w2422.nsk.ne.jp/~inoue/indexj.html
]
OpenLink ODBC 는 http://www.openlinksw.com/로부터 입수할 수 있습니다. 표준적인 ODBC 곳간
이안트·소프트웨어로 사용할 수 있기 때문에, 지원하고 있는 모든 플랫폼(Win,
Mac, Unix, VMS)로부터 PostgreSQL 의 ODBC 를 이용할 수 있습니다.
아마 그들은, 상용 품질의 지원의 필요한 사람들에게 팔고 있다고 생각합니다만, 후리우
아판은 언제라도 입수 가능 같습니다. 질문은, postgres95@openlink.co.uk 에 보내
주세요.
Programmer's Guide 의 ODBC 의 장도 봐 주세요.
2.2) PostgreSQL 를 Web 페이지와 제휴시키려면 어떤 툴이 있습니까?
데이타베이스를 뒤에 가지는 Web 페이지에 대한 훌륭한 소개가,
http://www.webreview.com에 있습니다.
Web 에의 확장을 위해서(때문에)는, PHP 가 탁월한 인터페이스가 되고 있습니다. http://
www.php.net/에 있습니다.
[역주:
PHP에 관한 일본어의 정보는, 2000년 4월 19일에 발족한 일본 PHP 유저회의 사이트
http://www.php.gr.jp/
혹은, 광천유찬의 사이트
http://www.geocities.jp/rui_hirokawa/php/
에 꽤 정리하고 있습니다.
마에다 미츠히로씨에 의해 만들어진 PHP/FI의 일본어 패치가 여러가지 사람의 손을 거쳐 PHP3. 0.7에 적용되었습니다.
현재는 PHPJ-DEV에서,
http://php.jpnnet.com/
사토씨를 중심으로 멀티 아르바이트 확장으로서 다시 만들어 최신판은 PHP-3. 0.18에 대응하고 있습니다.
츠카다 타쿠야씨는, PHP4 용의 일본어 관계의 확장 모듈
ftp://night.fminn.nagano.nagano.jp/php4/
(을)를 준비해 주시고 있습니다.
본가의 (분)편으로 국제화의 ML도 일어서 있습니다.
PHP-4. 2 로부터 멀티 아르바이트 확장 캐릭터 라인으로서 받아들여졌습니다.
]
처리가 복잡한 경우, 많은 사람은 Perl 인터페이스와 CGI.pm 나 mod_perl 를 사용해
.
[역주:
WDB 는, Web 로부터 DataBase 에의 Perl 의 Interface 입니다.
wdb-p95 에의 링크는 끊어져 버리고 있습니다. 아마, Perl DBI 경유로 DBD::Pg 의 이용이 가능이라고 생각됩니다.
현재, WDBI 라는 이름이 되어 있는 것
http://www.egroups.com/list/wdb-users/
라고 WDB의 이름 인 채의 것
http://www.i-con.dk/wdb/
(이)가 있습니다. 그 경위는 잘 모릅니다.
]
2.3) PostgreSQL 에 그래피컬·유저 인터페이스는 있습니까? 레포트지
네레이타나 묻어 문의 언어 인터페이스는 있습니까?
PgAccess 로 불리는 훌륭한 그래피컬·유저·인터페이스가 있어, 이
배포와 함께 출시됩니다. PgAccess 에는 리포트·제네레이터도 있습니다. Web 페이
지는 http://www.pgaccess.org/입니다.
ecpg 라고 하는 C 언어를 위한 묻어 SQL 문의 언어 인터페이스도 있습니다
.
2.4) 어떠한 언어로 PostgreSQL 와 통신으로 인가?
이하의 것이 있습니다:
· C (libpq, libpgeasy)
· C++ (libpq++)
·내장하기 C (ecpg)
· Java (jdbc)
· Perl (DBD::Pg and perl5)
· ODBC (odbc)
· Python (PyGreSQL)
· TCL (libpgtcl)
· C Easy API (libpgeasy)
· PHP ('pg_'함수군, Pear::DB)
그 외의 이용 가능한 인터페이스는 http://www.PostgreSQL.org/interfaces.html
에 있습니다.
[역주：
ruby의 작자인 기다리는 것도와 유키(matz@ZetaBITS.COM)씨와 기다리는 것도 물을 수 있는 유지(ematsu@pfu.co.jp)씨가
ruby 의 PostgreSQL 인터페이스를 만들었습니다. 현재의 유지 관리는 사이토 노보루씨가 하고 있습니다.
http://www.postgresql.jp/interfaces/ruby/
PgBash 는 사카이다아 아키라씨가 만든 bash 의 PostgreSQL 인터페이스입니다.
http://www.psn.co.jp/PostgreSQL/pgbash/
Bash 커멘드 라인으로 postgres 에 문의하고 할 수 있습니다.
Perl 의 모듈은 옛부터 있는 Pg 와 DBI 드라이버의 DBD::Pg 가 있어,
모두 Edmund Mergl 씨에 의하는 것으로 CPAN 사이트에 있습니다.
영안오사씨는 Palm 판의 libpq 가 개발되었습니다.
http://www.snaga.org/libpq/
]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
관리상의 질문
3.1) 어떻게 하면 /usr/local/pgsql 이외의 장소에 인스톨 할 수 있습니까?
간단한 방법은, configure 를 달리게 할 때 --prefix 옵션을 지정하는 것입니다
.
3.2) postmaster 를 달리게 하면(자), Bad System Call 라든지 코어·덤프 했다는 메신져
지가 나옵니다. 왜입니까?
다양한 문제가 생각됩니다만, 우선 최초로 당신의 커널에 System V IPC 의 확
장이 인스톨 되고 있는지를 확인해 봐 주세요. PostgreSQL 는 커널에 의한다
공유 메모리와 semaphore의 지원를 필요로 합니다.
3.3) postmaster 를 달리게 하려고 하면(자), IpcMemoryCreate 에러가 나옵니다. 왜입니다
인가?
커널이 공유 메모리를 가지는 설정으로 되어 있지 않았는지, 가 아니면, 커널에 대
해 사용할 수 있는 공유 메모리의 크기를 크게 설정할 필요가 있습니다. 구체적인 크기는
, 사용하고 있는 아키텍쳐와 postmaster 를 달리게 할 때 설정하는 버퍼의 수와 바
크엔드프로세스에 의존합니다. 대부분의 시스템에서는, 기정치의 버퍼 사이즈
인 채로, 적어도 약 1 MB가 필요합니다. PostgreSQL Administrator's Gide 에 공유 메
모리와 semaphore에 대한 정보의 상세가 있습니다.
3.4) postmaster를 달리게 하려고 하면(자), IpcSemaphoreCreate 에러가 나옵니다. 왜로
인가?
만약 에러 메세지가 IpcSemaphoreCreate: semget failed (No space left on
device)이면, 커널이 충분한 semaphore를 사용할 수 있도록(듯이) 구성되어 있지 않습니다.
Postgres는 잠재적인 연구 최종 단계 프로세스마다 하나의 semaphore를 필요로 합니다. 새아
그림의 해결책은 postmaster를 기동할 경우에, 연구 최종 단계 프로세스의 수를 보다 적고
제한을 하는 것입니다. 기정치의 32보다 작은 수의 파라미터를―N로 사용합니다. 보다 항구
적인 해결책은, 커널의 SEMMNS 와 SEMMNI 파라미터를 늘리는 것입니다.
조작 불능의 semaphore도 과도한 데이타베이스 액세스의 사이에 크래쉬를 일으킬 가능성이
있습니다.
만약, 에러 메세지가 무엇인가 다른 것이면, 커널의 구성으로 완전히 세마후
의 지원를 하고 있지 않을지도 모릅니다. PostgreSQL Administrator's Gide 에 공유
메모리와 semaphore에 대한 정보의 상세가 있습니다.
3.5) 다른 호스트로부터의 접속은 어떻게 제어합니까?
기정치에서는, PostgreSQL 는 unix 도메인 소켓을 사용하는 로컬 머신으로부터의 접속해
인가 허락하지 않습니다. postmaster 기동에 -i 플래그를 더해 $PGDATA/pg_hba.conf 파일
(을)를 적절히 고쳐, 호스트 주도형의 인증을 사용하지 않는 한은 다른 머신으로부터는 접속할 수 있는거야
있고지요. 이것에 의해 TCP/IP의 접속이 가능하게 됩니다.
조작 불능인 semaphore도 과도의 데이타베이스 액세스중에 크래쉬를 일으키는 것이
있습니다.
3.6) 보다 좋은 성능을 얻기 위해서(때문에)는, 데이타베이스·엔진을 어떻게 조정하면 양
있고입니까?
확실히 인덱스는 문의의 속도를 더합니다. EXPLAIN 커멘드로 PostgreSQL 가
어떻게 당신의 문의를 번역하고 있을까를 볼 수가 있고 그리고, 어느 인
덱스가 사용되고 있을까를 볼 수가 있습니다.
만약 INSERT 를 다용하고 있는 경우는, COPY 커멘드를 사용해 큰 배치처리로 그것을
행하는 것을 검토해 주세요. 이것은, INSERT 를 따로 따로 행하는 것보다 좀 더 고속으로. 차
에, BEGIN WORK/COMMIT 의 트랜잭션(transaction)·블록안에 없는 문장은, 그것들 자신이
각각의 트랜잭션(transaction)에 들어가 있다고 보여집니다. 몇개의 문장을 하나의 호랑이
자크션·블록 중(안)에서 행하는 것을 생각해 주세요. 이것에 의해 트란자크쇼
의 오버헤드가 줄어듭니다. 또, 큰 데이터의 변경을 행할 때는 인덱스
(을)를 한 번 제외해, 다시 만드는 것 를 생각해 봐 주세요.
튜닝의 옵션이 몇개인가 있습니다. postmaster 를 -o -F 옵션으로 오코시
동요하는 것에 의해, fsync()를 무효로 할 수가 있습니다. 이것에 의해, 각 트란
더 쿠션마다 fsync()로 디스크를 갱신하는 것을 멈추게 합니다.
postmaster -B 옵션을 사용해 연구 최종 단계·프로세스에 의해 사용되는 공유 메모리
-·버퍼를 크게 할 수도 있습니다. 만약, 이 파라미터를 높게 너무 높게 하면(자),
커널의 공유 메모리 공간의 제한치를 넘어 섬노래째에 postmaster 가 달리지 않고
되겠지요. 기정치에서는, 각각의 버퍼의 크기는 8K 로, 버퍼수는 64
입니다.
연구 최종 단계를 -S 옵션을 사용해, 각각의 연구 최종 단계·프로세스가 일시적
늘어놓고 대체에 의해 사용하는 메모리의 최대 사이즈를 늘릴 수도 있습니다. 그 -S 의 값
(은)는 킬로바이트 단위로, 기정치는 512 (즉, 512K)입니다.
또, CLUSTER 커멘드를 사용해, 테이블의 데이터를 인덱스에 맞추기 위해서(때문에)
그룹화 할 수도 있습니다. 자세하게는, 온라인 메뉴얼로 CLUSTER 를 봐 아래
차이.
3.7) 어떠한 데바그 기능을 사용할 수 있습니까?
PostgreSQL 는, 데바그를 위해서(때문에) 의미가 있는, 상태 정보를 보고하는 몇개의 기능을 가져
.
우선, --enable-cassert 옵션으로 configure 를 달리게 합니다. 그렇게 해서 컴파일
하는 것으로써, 많은 assert()가, 연구 최종 단계의 진척 상황을 감시해, 무엇인가 예기키
일이 일어나면(자) 프로그램을 정지하게 됩니다.
postmaster 와 postgres 의 양쪽 모두로 몇개의 데바그·옵션의 이용을 할 수 있습니다.
두, 다음과 같이 postmaster 를 기동할 때는 언제라도, 표준 출력과 에러 출력을 로그
·파일에 보내도록(듯이) 되어 있는 것을 확인해 주세요.
cd /usr/local/pgsql
. /bin/postmaster >server.log 2>&1 &
이것에 의해 PostgreSQL 의 최상부의 디렉토리에 server.log 파일이 놓여집니다
. 이 파일은 서버가 조우한 문제나 에러에 대해 유용한 정보를 포함합니다.
Postmaster 는 더욱 상세한 정보를 보고하기 위한 -d 옵션을 가집니다. 그 -d 오
프션은, 데바그·레벨을 지정합니다. 높은 데바그·레벨에서는, 큰 로그파
일을 생성하는 것에 주의하지 않으면 안됩니다.
만약, postmaster가 달리지 않으면, postgres 연구 최종 단계를 커멘드행으로부터 주등키
일이 생겨 직접 SQL문을 타이프 칠 수가 있습니다. 이 사용 방법은, 데바그 목적의
때만 추천합니다. 세미콜론이 아니고, 개행이 문의의 끝이 되는 것에 주
뜻 해 주세요. 만약, 데바그신볼을 넣어 컴파일 하고 있으면, 디버거를 사
라는 무엇이 일어나고 있을까를 볼 수가 있습니다. postmaster 로부터 연구 최종 단계를 개시했다
것은 아니기 때문에, 독립인 환경에서 달리고 있는 것이 아니라 락/연구 최종 단계와의 대화
의 문제가 중복 할 것은 없습니다.
만약, postmaster가 달리고 있으면, 어느 윈도우로 psql를 개시하면(자), psql 로 사원
postgres 프로세스의 PID가 발견됩니다. 디버거를 사용해 postgres의 PID에 아타
치(attach) 합니다. 디버거중에서 브레이크·포인트를 세트 해, psql 로부터 물어
맞댐을 발행합니다. 데바그를 위해서(때문에) postgres를 시동하는 경우는, PGOPTIONS="-W n" 를
설정할 수 있어 그리고, psql 를 개시합니다. 이것에 의해, n 초개시를 늦출 것이므로
, 디버거로 프로세스에 아탓치 해, breakpoint를 설정해, 개시부터 순서를 추
(이)라고 보고 갈 수가 있습니다.
PostgreSQL 프로그램에는, 데바그와 성능 측정에 매우 도움이 된다 -s나 -A나 -t 등의 오
프션이 있습니다.
뭐라고 하는 함수가 어느 정도 실행 시간을 소비하고 있을까를 보기 위해서(때문에), 프로 파일링(
프로필 첨부)로 컴파일 하는 일도 가능합니다. 그 연구 최종 단계의 프로 요금
르·파일은 pgsql/data/base/dbname 디렉토리에 격납되겠지요. 크라이
안트의 프로필은 클라이언트의 현행 디렉토리에 놓여지겠지요. Linux
그리고 착실한 프로 파일링을 실시하려면 -DLINUX_PROFILE 로 컴파일 할 필요가 있어
.
3.8) 접속하려고 할 때 'Sorry, too many clients'가 나오는 것은 왜입니까?
postmaster가 동시 시동할 수 있는 연구 최종 단계 프로세스에 대한 제한수를 늘릴 필요가 있어
.
기정의 최대 프로세스는 32 프로세스입니다. -N에 적절한 값을 인수로 해 postmaster를 재기동
하는지, PostgreSQL.conf 를 수정하는 것에 의해, 그 값을 늘릴 수가 있습니다.
. 기정의 구성에서는―N는 최대 1024까지 설정할 수 있습니다. 만약, 좀 더 필요하면 include/
config.h안의 MAXBACKENDS를 증가시켜, 재구축 합니다. 만약, 바란다면 configure의
--with-maxbackends 전환을 사용해, -N의 기정치를 구성시로 설정할 수 있습니다.
만약, -N 를 32보다 크게 한다면, -B도 기정의 64보다 큰 값에 증가시키는거야
구라고는 안 되고, -B 는 적어도 -N 의 2배는 없으면 안되어, 아마 최고 성능을
바란다면 그것보다 큰 값이 필요할 것입니다. 연구 최종 단계 프로세스를 싶게씨에게
와 여러가지 Unix 커널 구성 파라미터도 늘리는 것이 필요하게 인가 만약 키
응. 공유 메모리·블록의 최대치(SHMMAX), semaphore의 최대수(SEMMNS와 SEMMNI),
프로세스의 최대수(NPROC), 유저 마다의 최대 프로세스수(MAXUPRC), 여는 파일의 최대
수(NFILE와 NINODE 도 확인 사항에 포함됩니다. PostgreSQL에 용서되는 연구 최종 단계의 프
로세스수가 제한되고 있는 것은, 시스템의 리소스를 사용해 과연 끝내는 것을 피한다
유익입니다.
6.5보다 전의 버젼의 PostgreSQL에서는 연구 최종 단계의 최대수는 64였지만, 변경한다
에는, include/storage/sinvaladt.h안의 MaxBackendId 정수를 수정한 후에 재구축이 필
요점이었습니다.
3.9) pgsql_tmp 디렉토리안에는 무엇이 있습니까?
문의 실행 모듈에 의해 생성된 일시적인 파일입니다. 예를 들면, 만약
ORDER BY 구를 채우기 위해서(때문에) 연구 최종 단계의 -S 파라미터로 허가한 값보다 큰 스
페이스가 소트 시에 필요하다고 하면(자), 흘러넘친 데이터를 보관 유지하기 위해서 일시적인 파이
르가 몇개인가 생성됩니다.
일시적인 파일은 자동적으로 지워 없애질 것입니다만, 만약, 소트의 도중에 박크에
드가 크래쉬 해 버리면(자) 그렇게는 되지 않습니다. postmaster의 정지와 restart로 와
등의 파일은 디렉토리로부터 지워 떠나집니다.
[역주：
SYSLOGD 경유로 로그를 출력하려면 , 우선, configure 를 --enable-syslog
부착으로 달리게 한 후, 컴파일과 인스톨을 행합니다.
다음에, syslog.conf 에 local0. * 의 출력처를 지정해(환경 변수로 변경 가능),
syslogd 에 HUP 시그널을 보내 초기화해 둡니다. 그리고,
$PGDATA/pg_options 에 syslog=2 를 더해, postmaster 를 -S
옵션 첨부에서 서버 모드로 기동합니다. (버젼 7.1 으로부터는
pg_options 는 PostgreSQL.conf 가 되어 있습니다. )
]
3.10) PostgreSQL의 메이저 릴리즈를 업데이트 하는데 덤프와 restore를 하는거야
구라고는 안 되는 것은 왜입니까?
PostgreSQL 팀은 마이너 릴리즈에서는 작은 변경 밖에 행하지 않으므로, 7.2 로부터
7.2. 1 에의 업그레이드에는 덤프와 restore의 필요는 없습니다. 그러나, 메쟈
-릴리즈(예를 들어, 7.2에서 7.3에의 같은)에서는, 시스템 테이블이나 데이타파이
르의 내부 포맷의 변경을 자주 행합니다. 이러한 변경은 대부분 복잡해,
그 때문에 우리는 데이터 파일을 위한 후방 호환성을 유지할 수가 없습니다. 댄
프는 범용 포맷으로 데이터를 출력해, 그것을 새로운 내부 포맷에 읽어들이는 와
(이)가 할 수 있습니다.
동일 릴리즈에서는 디스크상에서의 포맷으로 변경은 없기 때문에, 업그레이드에는
덤프/restore가 아니고, pg_upgrade 스크립트를 사용할 수가 있습니다. 리리스노
트에는, pg_upgrade 가 이용 가능한 릴리즈인지 어떤지 기록되고 있습니다.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
조작상의 질문
4.1) 바이너리·커서와 통상 커서와의 엄밀한 차이는 무엇입니까?
상술은, 온라인 메뉴얼로 DECLARE 를 봐 주세요.
4.2) 최초의 수로우만을 SELECT 하려면 어떻게 합니까?
온라인 메뉴얼로 FETCH를 봐 주세요. 혹은, SELECT ... LIMIT....(을)를 사
(이)라고 봐 주세요.
비록, 갖고 싶은 것은 최초의 수로우만으로도, 모든 문의를 평가하지 않으면이라면
없을지도 모릅니다. ORDER BY 를 가진 문의를 사용하는 것을 생각해 봐 주세요. 도
해, ORDER BY에 맞은 인덱스가 있다고 하면(자) PostgreSQL는 요구된 최초의 수로
우만으로 평가할 수 있을지도 모릅니다만, 으로 견딜 수 있으면, PostgreSQL 는 의도한 로우가 생성함
까지 모든 로우를 평가해야 할지도 모릅니다.
4.3) 테이블이나 그 외의 정보의 리스트를 psql 로 보려면 어떻게 합니까?
psql의 원시 코드로서 쓰여진 pgsql/src/bin/psql/describe.c 파일을 읽는 와
(이)가 그 대답입니다. 거기에는, psql의 backslash 커멘드에 의한 출력을 위한 SQL
커멘드가 포함되어 있습니다. psql 에 -E 옵션을 붙여 기동하면, 준 팽이
드를 실행하기 위한 문의가 출력됩니다.
4.4) 테이블에서 컬럼의 삭제는 어떻게 합니까?
이 기능은, ALTER TABLE DROP COLUMN 로서 릴리즈 7.3 으로부터 더해졌습니다. 그것
까지의 버젼에서는, 그 대신에 이렇게 합니다:
BEGIN;
LOCK TABLE old_table;
SELECT ... -- 삭제하고 싶은 컬럼 이외의 컬럼을 모두 선택합니다.
INTO TABLE new_table
FROM old_table;
DROP TABLE old_table;
ALTER TABLE new_table RENAME TO old_table;
COMMIT;
[역주：컬럼의 추가는 ALTER TABLE ADD COLUMN 로 실시할 수 있습니다. ]
4.5) 로우, 테이블, 데이타베이스의 최대 사이즈는?
제한은 이하대로입니다.
데이타베이스의 최대 사이즈? 제한 없음 (1 TB 의 데이타베이스도 존재합니다)
테이블의 최대 사이즈? 16TB
로우의 최대 사이즈? 1.6TB
필드의 최대 사이즈? 1GB
테이블내에서의 최대 로우수? 제한 없음
테이블내에서의 최대 컬럼수? 컬럼의 형태에 의해250-1600
테이블내에서의 최대 인데크스수? 제한 없음
물론, 이것들은 실제는 무제한하지 않고, 디스크 용량과 메모리나 스왑스페이
스의 크기에 의해 제한됩니다. 성능은 이러한 값이 일외 큰 때에 여파를 접수
.
최대 테이블 사이즈의 16 TB는 operating system에 의한 거대 파일의 지원
(은)는 필요로 하지 않습니다. 거대한 테이블은 복수의 1 GB의 파일로 나누어 보존되기 때문에,
파일 시스템의 제한은 중요하지는 않습니다.
디폴트의 블록 사이즈를 32 k로 하면(자) 최대 테이블 사이즈와 최대 컬럼수가 증가
합니다.
4.6) 일반적인 텍스트 파일로부터 데이터를 보존하려면 , 데이타베이스의 디스크용
양은 어느 정도 필요합니다?
보통 텍스트 파일을 PostgreSQL 의 데이타베이스에 보존하려면 , 최대로 약 5배의
디스크 용량을 필요로 합니다.
예제로서 각 행에 정수와 텍스트 기술을 가지는 100,000행의 파일을 생각해 봅시다
. 텍스트의 캐릭터 라인의 평균 길이를 20바이트로 가정하면(자), 플랫 파일의 크기
(은)는 약 2.8MB 입니다. 이 데이터를 포함한 PostgreSQL 데이타베이스 파일의 크기는 다음의
같게 약 6.4 MB라고 추측할 수가 있습니다：
36 bytes: 각 로우의 헤더(개산)
24 bytes: 정수(int) 필드와 텍스트(text) 필드
+ 4 bytes: 페이지상의 tuple에의 포인터
----------------------------------------
64 bytes per row
PostgreSQL 의 데이터 페이지 사이즈는 8192바이트(8KB)이므로:
8192 bytes per page
------------------- = 128 rows per database page (절상)
64 bytes per row
100000 data rows
-------------------- = 782 database pages
128 rows per page
782 database pages * 8192 bytes per page = 6,406,144 bytes (6.4 MB)
인덱스는, 이 정도의 오바헷드는 요구합니다만, 인덱스 붙이고 된다
데이터를 포함한 이상, 그 나름대로 커집니다.
NULL는 비트 맵에 보존되고 있어, 그것들이 조금 스페이스를 사용합니다.
4.7) 정의된 테이블, 인덱스, 데이타베이스, 및, 유저를 어떻게
해 찾아냅니까?
psql 에는 여러가지 backslash·커멘드가 있어, 이러한 정보를 표시합니다.
backslash·커멘드의 종류를 보려면 \? (을)를 사용해 주세요.
또, pgsql/src/tutorial/syscat.source 파일을 달리게 해 봐 주세요. 그것은, 늪
산의 SELECT 문에 의해 필요한 정보를 데이타베이스의 시스템·테이블에서 꺼내
예시해 줍니다. 또, pg_ 로 시작되는 시스템 테이블에도 기술되고 있습니다. 접시
에, psql -l 는 모든 데이타베이스를 리스트 표시합니다.
4.8) 문의가 늦은 데다가, 인덱스를 사용하고 있는 모습이 없습니다. 왜입니까
?
인덱스는 자동적으로 모든 문의로 사용되는 것은 아닙니다. 테이블
하지만 최소 사이즈보다 크고, 문의로 그 몇 안 되는 퍼센티지의 로우를 선택한다
때만, 인덱스는 사용됩니다. 이것은 인덱스 스캔에 의해 일으켜지는 라
담인 디스크 액세스는, 테이블을 스트레이트하게 읽는 차례차례 주사보다 늦어지는 와
(이)가 있기 때문입니다.
인덱스를 사용할까를 결정하기 위해서(때문에), PostgreSQL 는 테이블에 대한 통계 정보를
가지지 않으면 안됩니다. 이 통계 정보는, VACUUM ANALYZE 또는, 단지 ANALYZE 를 사
라는 수집할 수가 있습니다. 통계 정보를 사용해 오브티마이자는 테이블안에 있다
로우수를 알아, 인덱스를 사용해야할 것인가 것의 결정을 보다 올바르게 할 수 있습니다. 통계 정보는
최적인 결합순서나 결합 방법을 결정하는데 있어서도 귀중한 것도 있습니다. 통계 정보의 수집은, 테
불의 내용이 변하면(자) 마다 반복 되어야 합니다.
인덱스는, 통상 ORDER BY 나 결합을 행하기 위해서(때문에)는 사용되지 않습니다. 차례차례 스캔
에 계속되는 명시적 소트는, 거대한 테이블의 인덱스 스캔보다 보통은 고속으로
.
그러나, ORDER BY와 짜 합쳐진 LIMIT 는, 테이블의 작은 부분을 돌려주기 위해서(때문에) 여행
여행 인덱스를 사용하겠지요. 실제, MAX()나 MIN()가 인덱스를 사용하지 않으면
해도, 이러한 값을 ORDER BY 와 LIMIT 를 사용해 인덱스를 사용해 꺼내는 와
(이)가 가능합니다:
SELECT col
FROM tab
ORDER BY col [ DESC ]
LIMIT 1;
LIKE 혹은 ~ 과 같은 와일드 카드 연산자는 특별한 환경에서 밖에 사용할 수 없습니다：
·검색 캐릭터 라인이 캐릭터 라인의 최초로 (듣)묻습니다. 예를 들어：
□ LIKE 패턴이%. 그리고 시작되지 않는다
□ ~ (정규 표현) 패턴은^. 그리고 시작되지 않으면 안 된다
·검색 캐릭터 라인을 캐릭터 클래스로부터 시작할 수 없습니다. 예를 들어,[a-e].
· ILIKE 나 ~* 와 같은 대문자와 소문자를 구별하지 않는 검색은 사용할 수 없습니다. 그 대신
, 이 FAQ의 4.12절로 설명하는 함수의 인덱스를 사용할 수 있습니다.
· initdb 에 대해서는, 디폴트로 C로케일이 사용되지 않으면 안됩니다.
[역주：강제적으로 인덱스를 사용하려면 SET enable_seqscan = off 를 실행합니다. ]
4.9) 문의 오브티마이자가 어떻게 문의를 평가하는지를 보려면 어때
합니까?
온라인 메뉴얼로 EXPLAIN 를 봐 주세요.
4.10) R-tree 인덱스란 무엇입니까?
R-tree 인덱스는 공간적인 데이터에 인덱스를 붙이기 위해서(때문에) 사용됩니다. 학
슈인젝스에서는 범위의 검색을 할 수 없습니다. 또, B-tree 인덱스에서는, 1차
원으로 밖에 범위의 검색을 할 수 없습니다. R-tree 인덱스이면 다차원의 데이터를 취급해라
. 예를 들어, 만약 R-tree 인덱스를 point 형의 속성에 붙일 수가 있으면(자)
그러자(면) 시스템은, 「직사각형에 둘러싸인 점을 모두 선택한다」라고 하는 것 같은 문의
에, 보다 효율 좋게 대답할 수 있습니다.
R-Tree 의 설계의 원전이 되는 권위 있는 논문은:
Guttman, A. "R-Trees: A Dynamic Index Structure for Spatial Searching. "
Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.
이 논문은, Stonebraker 교수의 "Readings in Database Systems" 에서도 다루어지고
(이)라고 있습니다.
[역주：
나라 첨단대의 이시카와가 고치지 않아보다 R-Tree 관계의 문헌을 소개해 받았습니다.
일본어 Postgres ML 의 어카이브(archive)로부터 "Subject: [postgres95 801] spatial data structures"
http://www.sra.co.jp/people/t-ishii/PostgreSQL/mhonarc/pgsql-jp/1996Oct/msg00007.html
(을)를 봐 주세요.
]
편성의 R-Tree 로 다각형이나 박스를 조작할 수 있습니다. 이론적으로는 R-Tree 는 좀 더 고
있고 차원을 조작하도록(듯이)도 확장할 수 있습니다. 실질적으로는, R-Tree 의 확장에는 약간의
작업이 필요해 해, 현재, 우리는 그것을 어떻게 할까에 대한 문서를 가져 지금
선.
[역주：
인터 위즈의 카타오카씨가 다차원 기하 오브젝트에의 확장 작업중입니다. 자세하게는,
http://www.interwiz.koganei.tokyo.jp/software/geometric/index.html
(을)를 봐 주세요.
]
4.11) 유전적 문의 최적화란 무엇입니까?
GEQO 모듈은, 많은 테이블을 결합할 경우에, 유전적 알고리즘(GA)으로 문합
조생을 고속화합니다. 이것에 의해, 해들 보고 부수어에 탐색을 행하지 않아도, 큰 결합
(join queries)(을)를 취급할 수가 있게 됩니다.
4.12) 정규 표현에서의 검색이나 대문자와 소문자를 구별하지 않는 정규 표현 검색은 어떻게 열매
나타냅니까? 대문자와 소문자를 구별하지 않는 검색을 위한 인덱스는 어떻게 사
있습니까?
~연산자는 정규 표현 조합을 행해,~* 는 대문자와 소문자를 구별하지 않는다
(case-insensitive) 정규 표현 조합을 실시합니다. 대문자와 소문자를 구별하지 않는 LIKE 연산
아이를 ILIKE 라고 합니다.
대문자와 소문자를 구별하지 않는 등치 비교 다음과 같이 표현할 수 있다：
SELECT *
FROM tab
WHERE lower(col) = 'abc';
표준 인덱스에서는 사용되지 않고, 그렇지만, 만약 함수 인덱스를 작
가 사용되겠지요.
CREATE INDEX tabindex ON tab (lower(col));
WHERE lower(textfield) LIKE lower(pattern)
4.13) 문의 중(안)에서, 필드가 NULL 인 것을 검출하려면 어떻게 합니까
?
컬럼을 IS NULL 와 IS NOT NULL 로 시험해 보겠습니다.
4.14) 여러가지 캐릭터형의 각각의 차이는 무엇입니까?
Type Internal Name Notes
--------------------------------------------------
"char" char 1 character
CHAR(n) bpchar 지정된 고정장이 되도록(듯이) 공백을 채울 수 있다
VARCHAR(n) varchar 최대장의 사이즈를 지정하는, 충전물 없음
TEXT text 길이에 상한이 없는 텍스트
BYTEA bytea 가변장의 아르바이트 배열(null-byte safe)
내부명에 뵙는 것은, 시스템·카탈로그를 조사할 때나, 에러 메세지를
받을 때입니다.
상기의 형태 중 후의 4개의 형태는 "varlena" 형입니다(즉, 디스크의 최초의 4 바이
트가 데이터 길이로, 그것의 뒤에 실제의 데이터가 계속됩니다). 이와 같이 실제의 공간은 선언함
크기보다 조금 커집니다. 그러나, 이러한 데이터형은 TOAST에 의해 압축함
충분하고 복수 로우에 건너 보존 되거나 해, 디스크 건성간은 생각했던 것보다 작아져
.
CHAR(n)는 언제나 길이가 같은 캐릭터 라인을 보존하는데 최적입니다. VARCHAR(n)는 가변장의 문장
자렬을 보존하는데 최적입니다만, 보존할 수 있는 캐릭터 라인의 길이에 제한이 있습니다. TEXT 는 장
에 제한이 없는 캐릭터 라인의 보존 유익의 것으로, 최대 1기가바이트입니다. BYTEA는, 부분적으로
NULL 의 아르바이트를 포함한 바이너리 데이터를 보존하기 위한의 것입니다.
4.15. 1) 통번(serial)/자동 증분 필드는 어떻게 만듭니까?
PostgreSQL 는 SERIAL 데이터형을 지원합니다. 컬럼상에 통번과 인덱스를 자
동작 이룹니다. 예를 들어,
CREATE TABLE person (
id SERIAL,
name TEXT
);
(은)는 자동적으로 다음과 같이 번역됩니다:
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);
CREATE UNIQUE INDEX person_id_key ON person ( id );
통번에 대한 좀 더 자세한 정보는, 온라인 메뉴얼로 create_sequence 를 람
주세요.
또, 각 로우의 OID 필드를 일의치로서 사용할 수도 있습니다. 그렇지만, 만약
도 데이타베이스를 덤프윤 로드할 필요가 있는 경우는, OID를 온존 하기 위해서
pg_dump 로 -o옵션을 사용하는지, 또는, COPY WITH OIDS 옵션을 사용할 필요가
. Bruce Momjian 의 것(http://www.PostgreSQL.org/docs/aw_pgsql_book)의
Numbering Rows의 장에 있어 남긴다.
4.15. 2) SERIAL 데이터형에 삽입되는 값은, 어떻게 하면 얻을 수 있습니까?
하나의 방법은, nextval() 함수를 사용해 그 값을 삽입하기 전(before)에 SEQUENCE 오
브제크트로부터 다음의 SERIAL 치를 꺼내, 그리고 실제로 삽입을 하는 것입니다.
4.15. 1 의 테이블의 예를 사용한다고 하면(자), 유사 언어에서는 이와 같이 됩니다.
new_id = execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
그렇게 해서, new_id 에 보존한 새로운 값을 다른 문의에(예를 들어, person 테이블
에 대한 외부 키(foreign key)와 같이) 사용하면(자) 좋을 것입니다. 자동적으로 만들어졌다
SEQUENCE 오브젝트의 이름은,<table>_<serialcolumn>_seq 와 같이 되어, 이 중
, table 와 serialcolumn 는 각각 테이블의 이름과 SERIAL 컬럼의 이름입니다.
혹은, 주어진 SERIAL치를, 그것이 기정치로서 삽입된 다음에(after),
currval() 함수를 사용해 꺼낼 수도 있습니다. 예를 들어,
execute("INSERT INTO person (name) VALUES ('Blaise Pascal')");
new_id = execute("SELECT currval('person_id_seq')");
마지막으로, INSERT문으로부터 돌아가는 OID를 사용해, 기정치를 찾아낼 수도 있습니다만, 그러나,
이것은 가장 이식성의 낮은 방식이지요. Perl의 DBI로 Edmund Mergl 가 만든 DBD::Pg
모듈을 사용하면, $sth->execute()의 뒤에 $sth->{pg_oid_status} 를 경유해 그
OID 치를 사용할 수 있도록(듯이) 할 수 있습니다.
4.15. 3) 다른 유저와의 경합 상태를 피하기 위해서(때문에)는, currval()와 nextval()는 사용하는거야
있고 편이 좋은 것일까요?
그것은 없습니다. currval()는, 모든 유저가 아닙니다만, 당신의 가방
엔드에게 줄 수 있었던 현재의 값을 돌려줍니다.
4.15. 4) 트랜잭션(transaction)가 중단했을 때에 이제 한 번 순차 순서 번호가 사용되지 않는거야
(은)는 왜입니까? 순차 순서/SERIAL 컬럼에 빈 곳이 있는 것은 왜입니까?
동시성을 개선하기 위해서, 실행중의 트랜잭션(transaction)에, 필요해 트랜잭션(transaction)가 종
끝 할 때까지 락 되지 않는 순차 순서치를 주고 있습니다. 이 때문에 트랜잭션(transaction)가
중단되면(자) 번호 할당에 갭을 일으킵니다.
4.16) OID 란 무엇입니까? TID 란 무엇입니까?
OID 와는 일의의 로우 ID 에 대한 PostgreSQL 의 대답입니다. PostgreSQL 중(안)에서 만들어지고
모든 로우는 일의의 OID 를 얻습니다. initdb 로 발생되는 OID 는 모두 16384
(include/access/transam.h 로부터)보다 작은 값입니다. initdb 후의 모든 OID (유
더 작성)은 그 이상의 값이 됩니다. 기정에서는, 이것들 모든 OID는 하나의 데이불이나
데이타베이스내에 머물지 않고, PostgreSQL Installation 전체 중(안)에서 일의입니다.
PostgreSQL 는 테이블간의 로우를 묶기 위해서(때문에), 그 시스템 테이블내에 OID
(을)를 사용합니다. 이 OID 는 특정의 유저의 로우를 식별하기 위해(때문에)나 결합 중(안)에서 사용되는 것
하지만 할 수 있습니다. OID 의 값을 보존하기 위해서는 OID 형을 컬럼에 사용하는 것을 추천합니다. 보다
빠르고 액세스 하기 위해서 OID 필드에 인덱스를 만들 수가 있습니다. OID
(은)는, 모든 데이타베이스로 사용되는 중앙 area로부터, 모든 새로운 로우에 할당
. OID 를 다른 무언가에 바꾸고 싶은, 혹은 원의 OID 도 테이블과 함께 카피하고 싶은거야
(이)라면, 할 수 없지는 않습니다.
CREATE TABLE new (old_oid oid, mycol int);
SELECT old_oid, mycol INTO new FROM old;
COPY new TO '/tmp/pgtable';
DELETE FROM new;
COPY new WITH OIDS FROM '/tmp/pgtable';
OID 는, 4바이트의 정수로서 보존되고 있으므로, 40억을 넘으면(자) 흘러넘쳐 버리겠죠
. 아무도 이것이 일어났다고 보고해 오는 사람은 없었습니다만, 그렇게 되기 전에 이 제한을
없애는 것을 계획하고 있습니다.
TID 는 특정의 물리 로우를 그 블록과 오프셋(offset)치로 식별하기 위해서 사용됩니다. TID
(은)는 로우가 수정되거나 재로드 되면(자) 바뀝니다. 그러한 TID 는, 물리 로우를 가리킨다
위해(때문에) 인덱스 기재로 사용됩니다.
4.17) PostgreSQL 로 사용되는 몇개의 용어의 의미는 무엇입니까?
몇개의 원시 코드나 낡은 문서안에는, 의 전문 분야 중(안)에서 좀 더 일반적으로
사용되는 전문 용어가 사용되고 있습니다.
·테이블(table), 관계(relation), 클래스(class)
·로우(row), 레코드(record), tuple(tuple)
·컬럼(column), 필드(field), 속성(attribute)
·취득(retrieve), 선택(select)
·치환(replace), 갱신(update)
·추가(append), 삽입(insert)
· OID, 연번(serial value)
·포털(portal), 커서(cursor)
·area 변수(range variable), 테이블명(table name), 테이블 별명(table alias)
일반적인 데이타베이스 용어의 리스트는：http://hea-www.harvard.edu/MST/simul/
software/docs/pkgs/pgsql/glossary/glossary.html 로 찾아낼 수 있습니다.
4.18) 에러 메세지 "ERROR: Memory exhausted in AllocSetAlloc()"가 나오는 것은
입니까?
아마, 시스템의 가상 메모리-를 모두 다 써 버려 버리고 있을 가능성이 있는지,
커널이 있는 리소스에 대해서도 개제한치가 너무 낮을 가능성이 있습니다. postmaster
(을)를 시동하기 전에 이것을 시험해 봐 주세요：
ulimit -d 262144
limit datasize 256m
쉘에 의해, 어느 쪽인지 하나가 성공하겠지만, 이것은 프로세스의 데이타세그
먼트 제한을 보다 높게 설정해, 아마 문의가 완결하게 되겠지요. 이
커멘드는 현행의 프로세스와 이 커멘드를 달리게 한 후에 만들어지는 모든 사브프로세
스에 대해 적용됩니다. 연구 최종 단계가 매우 많은 데이터를 돌려주기 위해서(때문에) SQL 크라이
안트로 문제가 계속되고 있다면, 클라이언트를 개시하기 전에 이것을 시험해 봐
주세요.
4.19) 어느 버젼의 PostgreSQL 를 달리게 하고 있을까를 조사하려면 어떻게 합니까?
psql 로부터 SELECT version(); 를 타이프 칩니다.
4.20) 라지·오브젝트의 조작으로 invalid large obj descriptor 를 받았습니다
. 왜입니까?
라지·오브젝트 조작을 할 때는, 전후에 BEGIN WORK와 COMMIT를 붙일 필요가
. 즉, lo_open ... lo_close를 끼웁니다.
현재는, PostgreSQL의 트랜잭션(transaction)의 위탁시에 라지·오브젝트·핸드
르를 닫는 것으로, lo_open 커멘드가 완료한 직후에 강제적으로 룰을 실행합니다
. 이 때문에, 최초로 핸들에 대해서 무엇인가를 하려고 하면(자), invalid large obj
descriptor(라지·오브젝트의 기술자가 부정)가 됩니다. 그래서, 만약, 트란
더 쿠션을 사용하는 것을 잊으면(자), (적어도 대부분의 시간) 일하고 있던 코드가 에
라멧세이지를 냅니다.
만약, ODBC와 같은 클라이언트 인터페이스를 사용이라면, auto-commit off를 설
정할 필요가 있을지도 모릅니다.
4.21) 현재의 시각이 디폴트가 되는 것 같은 컬럼은 어떻게 만듭니까?
CURRENT_TIMESTAMP를 사용합니다:
CREATE TABLE test (x int, modtime timestamp DEFAULT >CURRENT_TIMESTAMP );
4.22) 왜, IN를 사용하는 부문의가 매우 늦습니까?
현재, 외부 문의의 각 로우에 대해 부문의의 결과를 차례로 스캔 하는 것
에 의해, 부문의를 외부 문의에 결합하고 있습니다. 만약, 부문의가 몇 줄기
밖에 돌려주지 않고, 외부 문의가 많은 행을 돌려준다면, 당면은 IN를 EXISTS로 옮겨놓는 와
(와)과입니다：
SELECT *
FROM tab
WHERE col1 IN (SELECT subcol FROM subtab)
(을)를, 옮겨놓아：
SELECT *
FROM tab
WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col)
(으)로 합니다. 이것이 민첩합니다만, subcol는 색인 첨부 컬럼이어야 합니다. 이
제한은 장래의 릴리즈로 고치고 싶다고 생각하고 있습니다.
4.23) 외부 결합(outer join)은 어떻게 실현됩니까?
PostgreSQL 는 SQL 표준 구문을 사용하는 외부 결합(아우터 조인)을 지원합니다. 와
와에 2개의 예제가 있습니다.
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
혹은
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);
이러한 상징적인 문의에서는 t1.col 를 t2.col 와 결합해, t1 의 결합되고 (안)중
로우(t2 와 일치하지 않았던 로우)도 돌려주고 있습니다. RIGHT 결합은 t2 의 결합되고 (안)중
로우를 더하겠지요. FULL 결합은, 일치한 로우에 t1 와 t2 로부터는 결합되고 (안)중
로우를 돌려주겠지요. OUTER 라는 말은 옵션으로 LEFT, RIGHT, 또는 FULL
등의 결합이 가정되고 있습니다. 이전의 릴리즈에서는 외부 결합(outer join)을 UNION 와
NOT IN 를 사용해 시뮬레이트 할 수 있습니다. 예를 들어, tab1 와 tab2 를 결합할 때는,
다음의 문의로 두 개의 테이블을 외부 결합합니다.
SELECT tab1.col1, tab2.col2
FROM tab1, tab2
WHERE tab1.col1 = tab2.col1
UNION ALL
SELECT tab1.col1, NULL
FROM tab1
WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)
ORDER BY col1
4.24) 복수의 데이타베이스를 사용하는 문의는 어떻게 하면 할 수 있습니까?
현행의 데이타베이스 이외에의 문의 방법은 없습니다. 그렇다고 하는 것도 PostgreSQL가 데
타베이스 사양의 시스템 카탈로그를 읽어들이기 때문에, 거기에는, 비록 그체를
인 만큼 해라, 데이타베이스를 넘어 문의를 할 방법이 없습니다.
/contrib/dblink 는 데이타베이스간(cross-database)의 문의를 함수 소환에 의해
허락합니다. 물론, 클라이언트는 동시에 접속을 다른 데이타베이스에도 치지 않으면
안되어, 결과를 클라이언트측에서 merge 하지 않으면 안됩니다.
4.25) 함수로 복수의 로우 또는 컬럼을 돌려주려면 어떻게 합니까?
만약, PL/pgSQL 함수로 refcursors를 사용하면(자) 결과의 조를 돌려줄 수가 있습니다. http://
www.PostgreSQL.org/idocs/index.php? plpgsql-cursors.html 의 23.7. 3.3 절을 람하
차이.
4.26) 왜, PL/PgSQL 함수중에서 일시 테이블을 확실히 create/drop 하는 것이 성과
없는 것일까요?
PL/PgSQL 는 함수의 내용을 캐쉬해, 그 불행한 부작용이기 때문에, 만약 PL/PgSQL 함수
하지만 일시 테이블에 액세스 하면(자), 그 테이블은 나중에 드롭 되고 재작성됩니다
하지만, 함수가 다시 불려 가면(자), 캐쉬되고 있는 그 함수의 내용은 아직 낡은 한때
테이블을 여전히 가리키고 있기 때문입니다. 해결책은, PL/PgSQL 중(안)에서 EXECUTE 를 1
때 테이블 액세스를 위해서(때문에) 사용하는 것입니다. 이것으로, 매회 쿠에리-의 퍼스 해 수선을 오코시
넘겠지요.
4.27) 어떠한 리프리케이션오프션을 이용할 수 있습니까?
마스터/슬레이브의 리프리케이션오프션이 몇개인가 이용 가능합니다. 이러한
옵션에서는 마스터만이 데이타베이스를 변경할 수 있어 슬레이브는 데이타베이스를 독
뿐입니다. http://gborg.PostgreSQL.org/genpage? replication_research 의 마지막에
그것들을 일람으로 해 있습니다. 멀티-마스터의 리프리케이션에 의한 소류쇼
는 http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php 에서 작업
하지만 진행되고 있습니다.
[역주
JPUG 분산 트랜잭션(transaction) 개발 분과회에서는, 영안오사씨를 중심으로 2상
위탁의 구현을 행하고 있습니다.
http://www.postgresql.jp/subcommittee/dt/index.html
http://www.snaga.org/jpug-dt/
미타니 아츠시씨에 의한 쌍방향 리프리케이션 PGReplicate
http://www.csra.co.jp/~mitani/jpug/pgreplicate/
]
4.28) 어떠한 암호화 옵션을 이용할 수 있습니까?
· /contrib/pgcrypto SQL 문의 중(안)에서 사용하기 위한 많은 암호화를 포함합니다.
·클라이언트로부터 서버에의 전송을을 암호화하는 유일한 방법은 pg_hba.conf 중(안)에서
hostssl사것에 의합니다.
·버젼 7.3 에서는 데이타베이스 유저의 패스워드는 보존될 때에 자동적으로 암
호화 됩니다. 그것보다 전의 버젼에서는 postgresql.conf중에서
PASSWORD_ENCRYPTION를 유효하게 할 필요가 있습니다.
·서버는 암호화 파일 시스템을 사용해 달릴 수도 있습니다.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PostgreSQL의 확장에 대한 질문
5.1) 스스로 쓴 유저 정의 함수를 psql 중(안)에서 실행하면(자) 코어·덤프 해 버려
(은)는 왜입니까?
문제는 다양하게 생각됩니다만, 우선 최초로, 작성한 유저 정의 함수를 단독의 테스트프
로그 램으로 하고 시험해 봐 주세요.
5.2) PostgreSQL 용으로 쓴 조금 멋진 새로운 형태나 함수를 제공해 프로젝트에
공헌하고 싶습니다만?
여러분이 행한 확장을, pgsql-hackers 메일링·리스트에 보내 주세요. 저지
(이)라고, 장래는 그러한 확장이 contrib/ 서브 디렉토리안에 들어오게 되는 것으로 해
.
5.3) 타풀을 돌려주는 C언어의 함수는 어떻게 씁니까?
원리적으로는 가능합니다만, 이것에는 궁극의 묘기를 필요로 하기 때문에, 저자의 주위에서는 아직도 누구
안개연이 없습니다.
5.4) 소스·파일을 변경했습니다. 재컴파일 해도 변화를 볼 수 없는 것은 왜
입니까?
몇개의 Makefile 가 인클루드·파일에 대해서 적절한 의존관계(dependencies)를 가져 지금
선. make clean 를 하고 나서 한번 더 make 를 행하지 않으면 안됩니다. 만약, GCC
(을)를 값어치 있으면 configure 의 --enable-depend 옵션을 사용해, 컴파일러에
의존관계(dependencies)를 자동적으로 조사하게 할 수도 있습니다.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[역주：
일본어판의 제작에 대해서는 이하와 같습니다.
최종 갱신일: 2002년 10월 18일
번역자: 쿠와무라 윤 (Jun Kuwamura <juk@PostgreSQL.jp>)
이 FAQ의 일역의 작성에 해당해 협력을 해 주신 분들(경칭은 생략하겠습니다):
전중임(Minoru TANAKA <Tanaka.Minoru at keiken.co.jp>)
이시이 타츠오(Tatsuo ISHII <t-ishii at sra.co.jp>)
제등아는 사람(Tomohito SAITOH <tomos at elelab.nsc.co.jp>)
바바 하지메(Hajime BABA <baba at kusastro.kyoto-u.ac.jp>)
오카모토 카즈유키(Kazuyuki OKAMOTO <kokamoto at itg.hitachi.co.jp>)
코스게 쇼우이치(Shoichi Kosuge <s-kosuge at str.hitachi.co.jp>)
야마시타 요시유키(Yoshiyuki YAMASHITA <dica at eurus.dti.ne.jp>)
경계 신타로(Sintaro SAKAI <s_sakai at mxn.mesh.ne.jp>)
오고세 아키라 당신(Masami OGOSHI <ogochan at zetabits.com>)
이시카와 토시유키(Toshiyuki ISHIKAWA <tosiyuki at gol.com>)
혼다 시게루광(Shigehiro HONDA <fwif0083 at mb.infoweb.ne.jp>)
키키순서(Jun SESE <sesejun at linet.gr.jp>)
카미야영효(Hidetaka KAMIYA <hkamiya at catvmics.ne.jp>)
