From 969320c8b8b9d455d07fc0309cf7755d8fcf9b7c Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 1 Feb 2007 04:55:53 +0000 Subject: Chinese FAQ update Daojing.Zhou --- doc/src/FAQ/FAQ_chinese.html | 1881 ++++++++++++++++++++++-------------------- 1 file changed, 1006 insertions(+), 875 deletions(-) (limited to 'doc/src/FAQ') diff --git a/doc/src/FAQ/FAQ_chinese.html b/doc/src/FAQ/FAQ_chinese.html index d089d69eab5..5198cbf129d 100644 --- a/doc/src/FAQ/FAQ_chinese.html +++ b/doc/src/FAQ/FAQ_chinese.html @@ -1,875 +1,1006 @@ - - -
--最近更新:2005 年 06 月 02 日 星期五 22:27:35 CST -
-
- 目前维护人员:Bruce Momjian (pgman@candle.pha.pa.us)
- 中文版维护人员:doudou586 (doudou586_2005@yahoo.com.cn)
-
- 本文档的最新版本可以在 - http://www.postgresql.org/files/documentation/faqs/FAQ.html查看。 -
-
- 与操作系统平台相关的问题在http://www.postgresql.org/docs/faq/里回答。
-
-1.1)PostgreSQL 是什么?该怎么发音?
-1.2)PostgreSQL 的版权是什么?
-1.3)PostgreSQL 可以运行在哪些操作系统平台上?
-1.4)我从哪里能得到 PostgreSQL?
-1.5)我从哪里能得到对 PostgreSQL 的支持?
-1.6)我如何提交一个BUG报告?
-1.7)最新版的PostgreSQL 是什么?
-1.8)能够获取的最新文档有哪些?
-1.9)我如何了解已知的 BUG 或暂缺的功能?
-1.10)我应该怎样学习 SQL ?
-1.11)我应该怎样加入开发队伍?
-1.12)PostgreSQL 和其他数据库系统比起来如何?
-1.13)谁控制和管理PostgreSQL ?
-
-2.1)我们可以用什么语言和 PostgreSQL 打交道?
-2.2)有什么工具可以把 PostgreSQL 用于 Web 页面?
-2.3)PostgreSQL 拥有图形用户界面吗?
-
-3.1)我怎样才能把 PostgreSQL 装在 /usr/local/pgsql 以外的地方?
-3.2)我如何控制来自其他主机的连接?
-3.3)我怎样调整数据库引擎以获得更好的性能?
-3.4)PostgreSQL 里可以获得什么样的调试特性?
-3.5)为什么在试图连接登录时收到“Sorry, too many clients” 消息?
-3.6)为什么要在升级 PostgreSQL 主要发布版本时做 dump 和 restore ?
-3.7)(使用PostgreSQL)我需要使用什么计算机硬件 ?
-
-4.1)如何只选择一个查询结果的头几行?或是随机的一行?
-4.2)如何查看表、索引、数据库以及用户的定义?如何查看psql里用到的查询指令并显示它们?
-4.3)如何更改一个字段的数据类型?
-4.4)一行记录,一个表,一个库的最大尺寸是多少?
-4.5)存储一个典型的文本文件里的数据需要多少磁盘空间?
-4.6)为什么我的查询很慢?为什么这些查询没有利用索引?
-4.7)我如何才能看到查询优化器是怎样评估处理我的查询的?
-4.8)我怎样做正则表达式搜索和大小写无关的正则表达式查找?怎样利用索引进行大小写无关查找?
-4.9)在一个查询里,我怎样检测一个字段是否为 NULL?我如何才能准确排序而不论某字段是否含NULL值?
-4.10)各种字符类型之间有什么不同?
-4.11.1)我怎样创建一个序列号/自动递增的字段?
-4.11.2)我如何获得一个插入的序列号的值?
-4.11.3)使用 currval() 会导致和其他用户的紊乱情况(race condition)吗?
-4.11.4)为什么不在事务异常中止后重用序列号呢?为什么在序列号字段的取值中存在间断呢?
-4.12)什么是 OID?什么是 CTID ?
-4.13)为什么我收到错误信息“ERROR: Memory exhausted in AllocSetAlloc()”?
-4.14)我如何才能知道所运行的 PostgreSQL 的版本?
-4.15)我如何创建一个缺省值是当前时间的字段?
-4.16)如何进行 outer join (外连接)?
-4.17)如何使用涉及多个数据库的查询?
-4.18)如何让函数返回多行或多列?
-4.19)为什么我在使用PL/PgSQL函数存取临时表时会收到错误信息“relation with OID ##### does not exist”?
-4.20)目前有哪些数据复制方案可用?
-
-PostgreSQL 读作 Post-Gres-Q-L,有时候也简称为Postgres 。 -
-- PostgreSQL 是面向目标的关系数据库系统,它具有传统商业数据库系统的所有功能,同时又含有将在下一代 DBMS 系统的使用的增强特性。 - PostgreSQL 是自由免费的,并且所有源代码都可以获得。 -
- -- PostgreSQL 的开发队伍主要为志愿者,他们遍布世界各地并通过互联网进行联系,这是一个社区开发项目,它不被任何公司控制。 - 如想加入开发队伍,请参见开发人员常见问题(FAQ) - http://www.postgresql.org/files/documentation/faqs/FAQ_DEV.html -
- - --PostgreSQL的发布遵从经典的BSD版权。关于源代码的如何使用没有任何限制,我们很喜欢这种方式并且还没有打算改变它。 -
--下面就是我们使用的BSD版权内容: -
- -- 部分版权(c)1996-2005,PostgreSQL 全球开发小组,部分版权(c)1994-1996 加州大学董事 -
- -- (Portions copyright (c) 1996-2005, 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.)
-
-
- 一般说来,一个现代的 UNIX 兼容的平台都能运行 PostgreSQL 。在安装指南里列出了发布时经过明确测试的平台。 -
- -- PostgreSQl也可以直接运行在基于微软Windows-NT的操作系统,如Win2000,WinXP 和 Win2003,已制作完成的安装包可从 - http://pgfoundry.org/projects/pginstaller下载,基于MSDOS的Windows操作系统 - (Win95,Win98,WinMe)需要通过Cygwin模拟环境运行PostgreSQL。 -
- -- 同时也有一个为Novell Netware 6开发的版本可从 http://forge.novell.com 获取,为OS/2开发的版本可从 - - http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=postgreSQL&stype=all&sort=type&dir=%2F -
- -- 通过浏览器可从http://www.postgresql.org/ftp/下载,也可通过FTP,从 - ftp://ftp.PostgreSQL.org/pub/站点下载。 -
- - -- PostgreSQL社区通过邮件列表为其大多数用户提供帮助,加入邮件列表的主站点是 http://www.postgresql.org/community/lists/,一般情况下,先加入General 或 Bug邮件列表是一个较好的开始。 -
- -- 主要的IRC频道是在FreeNode(irc.freenode.net)的#postgresql,为了连上此频道,可以使用UNIX程序irc,其指令格式: - irc -c '#postgresql' "$USER" irc.freenode.net ,或者使用其他IRC客户端程序。在此网络中还存在一个PostgreSQL的西班牙频道(#postgersql-es)和法语频道 - (#postgresql-fr)。同样地,在EFNET上也有一个PostgreSQL的交流频道。 -
- -- 商业支持公司的列表在 http://techdocs.postgresql.org/companies.php。 -
- - - -- 可访问 http://www.postgresql.org/support/submitbug,填写Bug上报表格即可。 -
- -- 同样也可访问ftp站点ftp://ftp.PostgreSQL.org/pub/ 检查有无更新的PostgreSQL版本或补丁。 -
- - - -- PostgreSQL 最新的版本是版本 8.0.2 (译注:现最新版本为8.0.3)。 -
- -- 我们计划每年发布一个主要版本,每几个月发布一个小版本。 -
- - -- PostgreSQL包含大量的文档,主要有一些手册,手册页和一些的测试例子。参见 /doc 目录(译注:应为 $PGHOME/doc)。 - 你还可以在线浏览 PostgreSQL 的手册,其地址是:http://www.PostgreSQL.org/docs。 -
-- 有两本关于 PostgreSQL 的书在线提供,在 - http://www.PostgreSQL.org/docs/awbook.html - 和 http://www.commandprompt.com/ppbook/ 。 - 也有大量的PostgreSQL书籍可供购买,其中最为流行的一本是由Korry Douglas编写的。在 - http://techdocs.PostgreSQL.org/techdocs/bookreviews.php上 - 上有大量有关PostgreSQL书籍的简介。 - 在 http://techdocs.PostgreSQL.org/上收集了有关 PostgreSQL 的大量技术文章。 -
- -- 客户端的命令行程序psql有一些以 \d 开头的命令,可显示关于类型,操作符,函数,汇总等的信息,使用 \? 可以显示所有可用的命令。 -
- -- 我们的 web 站点包含更多的文档。 -
- -- PostgreSQL 支持一个扩展了的 SQL-92 的子集。参阅我们的TODO 列表,获取一个已知Bug,暂缺的功能和将来的计划。 -
- - -- 首先考虑上述提到的与PostgreSQL相关的书籍,另外一本是Teach Yourself SQL in 21 Days, Second Edition, - 我们的许多用户喜欢The Practical SQL Handbook Bowman, Judith S., et al., Addison-Wesley,其他的则喜欢 - The Complete Reference SQL, Groff et al., McGraw-Hill。 -
- - -- 详见 Developer's FAQ 。 -
- - --评价软件有好几种方法:特性,性能,可靠性,支持和价格。 -
-- 如果你在寻找PostgreSQL的掌门人,或是什么中央委员会,或是什么所属公司,你只能放弃了---因为一个也不存在,但我们的确有一个 - 委员会和CVS管理组,但这些工作组的设立主要是为了进行管理工作而不是对PostgreSQL进行控制,PostgreSQL项目是由任何人均 - 可参加的开发人员社区和所有用户控制的,你所需要做的就是加入邮件列表,参与讨论即可(要参与PostgreSQL的开发详见 - Developer's FAQ 获取信息)。 -
- -- PostgreSQL(缺省情况)只安装有C和内嵌式C的接口,其他的接口都是独立的项目,能够分别下载,这些接口项目独立的好处 - 是他们可以有各自的发布计划和各自独立的开发组。 -
-- 一些编程语言如PHP都有访问 PostgreSQL 的接口,Perl,TCL,Python以及很多其他语言的接口在 - http://gborg.postgresql.org 上的Drivers/Interfaces小节可找到, - 并且通过Internet很容易搜索到。 -
- - - -- 一个介绍以数据库为后台的挺不错的站点是:http://www.webreview.com。 -
-- 对于 Web 集成,PHP 是一个极好的接口。它在:http://www.php.net/。 -
-- 对于复杂的任务,很多人采用 Perl 接口和 CGI.pm 或 mod_perl 。 -
- - -- 是的,在 http://techdocs.postgresql.org/guides/GUITools有一个详细的列表。 -
- - - -- 在运行 configure 时加上 --prefix 选项。 -
- - -- 缺省时,PostgreSQL 只允许通过 unix 域套接字或TCP/IP方式且来自本机的连接。 - 你只有在修改了配置文件postgresql.conf中的listen_addresses,且也在配置文件pg_hba.conf中打开了 - 主机为基础( host-based )的身份认证,并重新启动PostgreSQL,否则其他机器是不能与你的PostgreSQL服务器连接的。 -
- - -- 有三个主要方面可以提升PostgreSQL的潜能。 -
- -- PostgreSQL 有很多类似 log_* 的服务器配置变量可用于查询的打印和进程统计,而这些工作对调试和性能测试很有帮助。 -
- - - -- 这表示你已达到缺省100个并发后台进程数的限制,你需要通过修改postgresql.conf文件中的max_connections值来 - 增加postmaster的后台并发处理数,修改后需重新启动postmaster。 -
- - -- PostgreSQL 开发组对每次小的升级仅做了较少的修改,因此从 7.4.0 升级到 7.4.1 不需要 dump 和 restore。 - 但是主要的升级(例如从 7.3 到 7.4)通常会修改系统表和数据表的内部格式。 - 这些变化一般比较复杂,因此我们不维数据文件的向后兼容。 - dump 将数据按照通用的格式输出,随后可以被重新加载并使用新的内部格式。 -
- -- 由于计算机硬件大多数是兼容的,人们总是倾向于相信所有计算机硬件质量也是相同的。事实上不是, - ECC RAM(带奇偶校验的内存),SCSI (硬盘)和优质的主板比一些便宜货要更加可靠且具有更好的性能。PostgreSQL几乎可以运行在任何硬件上, - 但如果可靠性和性能对你的系统很重要,你就需要全面的研究一下你的硬件配置了。在我们的邮件列表上也有关于 - 硬件配置和性价比的讨论。 -
- - -- 如果你只是要提取几行数据,并且你在执行查询中知道确切的行数,你可以使用LIMIT功能。 - 如果有一个索引与 ORDER BY中的条件匹配,PostgreSQL 可能就只处理要求的头几条记录, - (否则将对整个查询进行处理直到生成需要的行)。如果在执行查询功能时不知道确切的记录数, - 可使用游标(cursor)和FETCH功能。 -
-- 可使用以下方法提取一行随机记录的: -
-- SELECT cols - FROM tab - ORDER BY random() - LIMIT 1 ; -- - - -
- 在psql中使用 \dt 命令来显示数据表的定义,要了解psql中的完整命令列表可使用\? ,另外,你也可以阅读 psql 的源代码 - 文件pgsql/src/bin/psql/describe.c,它包括为生成psql反斜杠命令的输出的所有 SQL 命令。你还可以带 -E 选项启动 psql, - 这样它将打印出执行你在psql中所给出的命令的内部实际使用的SQL查询。PostgreSQL也提供了一个兼容SQL的INFORMATION SCHEMA接口, - 你可以从这里获取关于数据库的信息。 -
-- 在系统中有一些以pg_ 打头的系统表也描述了表的定义。 -
-- 使用 psql -l 指令可以列出所有的数据库。 -
-- 也可以浏览一下 pgsql/src/tutorial/syscat.source文件,它列举了很多可从数据库系统表中获取信息的SELECT语法。 -
- - -- 在8.0版本里更改一个字段的数据类型很容易,可使用 ALTER TABLE ALTER COLUMN TYPE 。 -
-- 在以前的版本中,可以这样做: -
-- BEGIN; - ALTER TABLE tab ADD COLUMN new_col new_data_type; - UPDATE tab SET new_col = CAST(old_col AS new_data_type); - ALTER TABLE tab DROP COLUMN old_col; - COMMIT; --
- 你然后可以使用VACUUM FULL tab 指令来使系统收回无效数据所占用的空间。 -
- -- 下面是一些限制: -
--- -- -
-- 一个数据库最大尺寸? 无限制(已存在有 32TB 的数据库) - 一个表的最大尺寸? 32 TB - 一行记录的最大尺寸? 1.6 TB - 一个字段的最大尺寸? 1 GB - 一个表里最大行数? 无限制 - 一个表里最大列数? 250-1600 (与列类型有关) - - 一个表里的最大索引数量? 无限制
- 当然,实际上没有真正的无限制,还是要受可用磁盘空间、可用内存/交换区的制约。 - 事实上,当这些数值变得异常地大时,系统性能也会受很大影响。 -
- -- 表的最大尺寸 32 TB 不需要操作系统对大文件的支持。大表用多个 1 GB 的文件存储,因此文件系统尺寸的限制是不重要的。 -
-- 如果缺省的块大小增长到 32K ,最大的表尺寸和最大列数还可以增加到四倍。 -
- - -- 一个 Postgres 数据库(存储一个文本文件)所占用的空间最多可能需要相当于这个文本文件自身大小5倍的磁盘空间。 -
-- 例如,假设有一个 100,000 行的文件,每行有一个整数和一个文本描述。 - 假设文本串的平均长度为20字节。文本文件占用 2.8 MB。存放这些数据的 PostgreSQL 数据库文件大约是 6.4 MB: -
-- 32 字节: 每行的头(估计值) - 24 字节: 一个整数型字段和一个文本型字段 - + 4 字节: 页面内指向元组的指针 - ---------------------------------------- - 60 字节每行 - - PostgreSQL 数据页的大小是 8192 字节 (8 KB),则: - - 8192 字节每页 - ------------------- = 136 行/数据页(向下取整) - 60 字节每行 - - 100000 数据行 - -------------------- = 735 数据页(向上取整) - 128 行每页 - - 735 数据页 * 8192 字节/页 = 6,021,120 字节(6 MB) -- -
- 索引不需要这么多的额外消耗,但也确实包括被索引的数据,因此它们也可能很大。 -
-- 空值NULL存放在位图中,因此占用很少的空间。 -
- -- 并非每个查询都会自动使用索引。只有在表的大小超过一个最小值,并且查询只会选中表中较小比例的记录时才会采用索引。 - 这是因为索引扫描引起的随即磁盘存取可能比直接地读取表(顺序扫描)更慢。 -
-- 为了判断是否使用索引,PostgreSQL必须获得有关表的统计值。这些统计值可以使用 VACUUM ANALYZE,或 ANALYZE 获得。 - 使用统计值,优化器知道表中有多少行,就能够更好地判断是否利用索引。 - 统计值对确定优化的连接顺序和连接方法也很有用。在表的内容发生变化时,应定期进行统计值的更新收集。 -
-- 索引通常不用于 ORDER BY 或执行连接。对一个大表的一次顺序扫描,再做一个显式的排序通常比索引扫描要快。 -
- -- 但是,在 LIMIT 和 ORDER BY 结合使用时经常会使用索引,因为这只会返回表的一小部分。 - 实际上,虽然 MAX() 和 MIN() 并不使用索引,通过对 - ORDER BY 和 LLIMIT 使用索引取得最大值和最小值也是可以的: -
-- SELECT col - FROM tab - ORDER BY col [ DESC ] - LIMIT 1; --
- 如果你确信PostgreSQL的优化器使用顺序扫描是不正确的,你可以使用SET enable_seqscan TO 'off'
指令,
- 然后再次运行查询,你就可以看出使用一个索引扫描是否确实要快一些。
-
- 当使用通配符操作,例如 LIKE 或 ~ 时,索引只能在特定的情况下使用: -
-text_pattern_ops
索引来用于LIKE的索引。
- - 在8.0之前的版本中,除非要查询的数据类型和索引的数据类型相匹配,否则索引经常是未被用到,特别是对int2,int8和数值型的索引。 -
- -- 参考 EXPLAIN 手册页。 -
- -- 操作符 ~ 处理正则表达式匹配,而 ~* 处理大小写无关的正则表达式匹配。大写些无关的 LIKE 变种成为 ILIKE。 -
-- 大小写无关的等式比较通常写做: -
-SELECT * - FROM tab - WHERE lower(col) = 'abc'; --
- 这样将不会使用标准的索引。但是可以创建一个可被利用的函数索引: -
-CREATE INDEX tabindex ON tab (lower(col)); -- -
- 用 IS NULL 和 IS NOT NULL 测试这个字段,具体方法如下: -
-SELECT * - FROM tab - WHERE col IS NULL; -- -
为了能对含 NULL字段排序,可在 ORDER BY 条件中使用 IS NULL和 - IS NOT NULL 修饰符,条件为真 true 将比条件为假false 排在前面,下面的例子就会将含 - NULL 的记录排在结果的上面部分: -
-SELECT * - FROM tab - ORDER BY (col IS NOT NULL) -- -
-- -- -
-- 类型 内部名称 说明 - VARCHAR(n) varchar 指定了最大长度,变长字符串,不足定义长度的部分不补齐 - CHAR(n) bpchar 定长字符串,实际数据不足定义长度时,以空格补齐 - TEXT text 没有特别的上限限制(仅受行的最大长度限制) - BYTEA bytea 变长字节序列(使用NULL也是允许的) - - "char" char 一个字符
- 在系统表和在一些错误信息里你将看到内部名称。 -
-- 上面所列的前四种类型是"varlena"(变长)类型(也就是说,开头的四个字节是长度,后面才是数据)。 - 于是实际占用的空间比声明的大小要多一些。 - 然而这些类型都可以被压缩存储,也可以用 TOAST 脱机存储,因此磁盘空间也可能比预想的要少。 -
-- VARCHAR(n) 在存储限制了最大长度的变长字符串是最好的。 - TEXT 适用于存储最大可达 1G左右但未定义限制长度的字符串。 -
-- CHAR(n) 最适合于存储长度相同的字符串。 CHAR(n)会根据所给定的字段长度以空格补足(不足的字段内容), - 而 VARCHAR(n) 只存储所给定的数据内容。 - BYTEA 用于存储二进制数据,尤其是包含 NULL 字节的值。这些类型具有相似的性能特性。 -
- - - -- 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_sequence 手册页获取关于序列的更多信息。 -
- - -- 一种方法是在插入之前先用函数 nextval() 从序列对象里检索出下一个 SERIAL 值,然后再显式插入。使用 - 4.11.1 里的例表,可用伪码这样描述: -
-- new_id = execute("SELECT nextval('person_id_seq')"); - execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')"); --
- 这样还能在其他查询中使用存放在 new_id 里的新值(例如,作为 person 表的外键)。 - 注意自动创建的 SEQUENCE 对象的名称将会是 <table>_<serialcolumn>_seq, - 这里 table 和 serialcolumn 分别是你的表的名称和你的 SERIAL 字段的名称。 -
-- 类似的,在 SERIAL 对象缺省插入后你可以用函数 currval() 检索刚赋值的 SERIAL 值,例如: -
-- execute("INSERT INTO person (name) VALUES ('Blaise Pascal')"); - new_id = execute("SELECT currval('person_id_seq')"); -- -
- 不会。currval() 返回的是你本次会话进程所赋的值而不是所有用户的当前值。
-
- 为了提高并发性,序列号在需要的时候赋予正在运行的事务,并且在事务结束之前不进行锁定, - 这就会导致异常中止的事务后,序列号会出现间隔。 -
- -- PostgreSQL 里创建的每一行记录都会获得一个唯一的OID,除非在创建表时使用WITHOUT OIDS选项。 - OID创建时会自动生成一个4字节的整数,所有 OID 在整个 PostgreSQL 中均是唯一的。 然而,它在超过40亿时将溢出, - OID此后会出现重复。PostgreSQL 在它的内部系统表里使用 OID 在表之间建立联系。 -
-- 在用户的数据表中,最好是使用SERIAl来代替OID - 因为SERIAL只是保证在单个表中数据是唯一的,这样它溢出的可能性就非常小了, - SERIAL8可用来保存8字节的序列号字段。 -
- -- CTID 用于标识带着数据块(地址)和(块内)偏移的特定的物理行。 - CTID 在记录被更改或重载后发生改变。索引入口使用它们指向物理行。 -
- - -- 这很可能是系统的虚拟内存用光了,或者内核对某些资源有较低的限制值。在启动 postmaster 之前试试下面的命令: -
-- ulimit -d 262144 - limit datasize 256m --
- 取决于你用的 shell,上面命令只有一条能成功,但是它将把你的进程数据段限制设得比较高, - 因而也许能让查询完成。这条命令应用于当前进程,以及所有在这条命令运行后创建的子进程。 - 如果你是在运行SQL客户端时因为后台返回了太多的数据而出现问题,请在运行客户端之前执行上述命令。 -
- -
- 从 psql 里,输入 SELECT version();
指令。
-
- 使用 CURRENT_TIMESTAMP: -
-- CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- - -
- PostgreSQL 采用标准的 SQL 语法支持外连接。这里是两个例子: -
-- 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 OUTER JOIN)将返回 t2 中未连接的行。 - 完全外连接(FULL OUTER JOIN)将返回 t1 和 t2 中未连接的行。 - 关键字 OUTER 在左[外]连接、右[外]连接和完全[外]连接中是可选的,普通连接被称为内连接(INNER JOIN)。 -
- - -- 没有办法查询当前数据库之外的数据库。 - 因为 PostgreSQL 要加载与数据库相关的系统目录(系统表),因此跨数据库的查询如何执行是不定的。 -
-- 附加增值模块contrib/dblink允许采用函数调用实现跨库查询。当然用户也可以同时连接到不同的数据库执行查询然后在客户端合并结果。 -
- -- 在函数中返回数据记录集的功能是很容易使用的,详情参见: - http://techdocs.postgresql.org/guides/SetReturningFunctions -
- -- PL/PgSQL会缓存函数的内容,由此带来的一个不好的副作用是若一个 PL/PgSQL - 函数访问了一个临时表,然后该表被删除并重建了,则再次调用该函数将失败, - 因为缓存的函数内容仍然指向旧的临时表。解决的方法是在 PL/PgSQL 中用EXECUTE - 对临时表进行访问。这样会保证查询在执行前总会被重新解析。 -
- -- “复制”只是一个术语,有好几种复制技术可使用,每种都有优点和缺点: -
-- 主/从复制方式是允许一个主服务器接受读/写的申请,而多个从服务器只能接受读/SELECT查询的申请, - 目前最流行且是免费的主/从 PostgreSQL复制方案是 - Slony-I 。 -
-- 多个主服务器的复制方式允许将读/写的申请发送给多台的计算机,这种方式由于需要在多台服务器之间同步数据变动 - 可能会带来较严重的性能损失,Pgcluster是目前这种方案 - 中最好的,而且还可以免费下载。 -
-- 也有一些商业需付费和基于硬件的数据复制方案,支持上述各种复制模型。 -
- - - - - - + + + + + + 鏈杩戞洿鏂帮細2007 骞 1 鏈 5 鏃 鏄熸湡浜 15:40:20 EST
+ 涓枃鐗堟渶杩戞洿鏂帮細2007 骞 1 鏈 29 鏃 鏄熸湡涓 22:48:04 CST
+
鐩墠缁存姢浜哄憳锛欱ruce Momjian (pgman@candle.pha.pa.us)
+ 涓枃鐗堢淮鎶や汉鍛橈細Daojing.Zhou锛doudou586@gmail.com锛
+
+ 鏈枃妗g殑鏈鏂扮増鏈彲浠ュ湪 + http://www.postgresql.org/files/documentation/faqs/FAQ.html鏌ョ湅銆 +
+
+ 涓庢搷浣滅郴缁熷钩鍙扮浉鍏崇殑闂鍙湪http://www.postgresql.org/docs/faq/閲屾壘鍒扮瓟妗堛
+
+1.1)PostgreSQL 鏄粈涔堬紵璇ユ庝箞鍙戦煶锛
+1.2)璋佹帶鍒跺拰绠$悊PostgreSQL 锛
+1.3)PostgreSQL鐨勭増鏉冩槸浠涔堬紵
+1.4)PostgreSQL鍙互杩愯鍦ㄥ摢浜涙搷浣滅郴缁熷钩鍙颁笂锛
+1.5)鎴戜粠鍝噷鑳藉緱鍒癙ostgreSQL锛
+
+1.6)鏈鏂扮増鐨凱ostgreSQL 鏄粈涔堬紵
+1.7)鎴戜粠鍝噷鑳藉緱鍒板PostgreSQL 鐨勬敮鎸侊紵
+1.8)鎴戝浣曟彁浜や竴涓狟UG鎶ュ憡锛
+1.9)鎴戝浣曚簡瑙e凡鐭ョ殑 BUG 鎴栨殏缂虹殑鍔熻兘锛
+1.10)鑳藉鑾峰彇鐨勬渶鏂版枃妗f湁鍝簺锛
+1.11)鎴戝簲璇ユ庢牱瀛︿範 SQL 锛
+
+1.12)濡備綍鎻愪氦琛ヤ竵鎴栨槸鍔犲叆寮鍙戦槦浼嶏紵
+1.13)PostgreSQL 鍜屽叾浠栨暟鎹簱绯荤粺姣旇捣鏉ュ浣曪紵
+
+2.1)鎴戜滑鍙互鐢ㄤ粈涔堣瑷鍜孭ostgreSQL 鎵撲氦閬擄紵
+2.2)鏈変粈涔堝伐鍏峰彲浠ユ妸PostgreSQL 鐢ㄤ簬 Web 椤甸潰锛
+
+2.3)PostgreSQL 鎷ユ湁鍥惧舰鐢ㄦ埛鐣岄潰鍚楋紵
+
+3.1)鎴戞庢牱鎵嶈兘鎶奝ostgreSQL 瑁呭湪 /usr/local/pgsql 浠ュ鐨勫湴鏂癸紵
+3.2)鎴戝浣曟帶鍒舵潵鑷叾浠栫數鑴戠殑杩炴帴锛
+3.3)鎴戞庢牱璋冩暣鏁版嵁搴撴湇鍔″櫒浠ヨ幏寰楁洿濂界殑鎬ц兘锛
+
+3.4)PostgreSQL 閲屽彲浠ヨ幏寰椾粈涔堟牱鐨勮皟璇曠壒鎬э紵
+3.5)涓轰粈涔堝湪璇曞浘杩炴帴鐧诲綍鏃舵敹鍒扳淪orry, too many clients鈥 娑堟伅锛
+3.6)PostgreSQL鐨勫崌绾ц繃绋嬫湁鍝簺鍐呭锛
+3.7)(浣跨敤PostgreSQL)鎴戦渶瑕佷娇鐢ㄤ粈涔堣绠楁満纭欢 锛
+
+4.1) 濡備綍鍙夋嫨涓涓煡璇㈢粨鏋滅殑澶村嚑琛岋紵鎴栨槸闅忔満鐨勪竴琛岋紵
+4.2) 濡備綍鏌ョ湅琛ㄣ佺储寮曘佹暟鎹簱浠ュ強鐢ㄦ埛鐨勫畾涔夛紵濡備綍鏌ョ湅psql閲岀敤鍒扮殑鏌ヨ鎸囦护骞舵樉绀哄畠浠紵
+4.3) 濡備綍鏇存敼涓涓瓧娈电殑鏁版嵁绫诲瀷锛
+4.4) 鍗曟潯璁板綍锛屽崟涓〃锛屼竴涓暟鎹簱鐨勬渶澶ч檺鍒舵槸澶氬皯锛
+4.5) 瀛樺偍涓涓吀鍨嬬殑鏂囨湰鏂囦欢閲岀殑鏁版嵁闇瑕佸灏戠鐩樼┖闂达紵
+
+4.6) 涓轰粈涔堟垜鐨勬煡璇㈠緢鎱紵涓轰粈涔堣繖浜涙煡璇㈡病鏈夊埄鐢ㄧ储寮曪紵
+4.7) 鎴戝浣曟墠鑳界湅鍒版煡璇紭鍖栧櫒鏄庢牱璇勪及澶勭悊鎴戠殑鏌ヨ鐨勶紵
+4.8) 鎴戞庢牱鍋氭鍒欒〃杈惧紡鎼滅储鍜屽ぇ灏忓啓鏃犲叧鐨勬鍒欒〃杈惧紡鏌ユ壘锛熸庢牱鍒╃敤绱㈠紩杩涜澶у皬鍐欐棤鍏虫煡鎵撅紵
+4.9) 鍦ㄤ竴涓煡璇㈤噷锛屾垜鎬庢牱妫娴嬩竴涓瓧娈垫槸鍚︿负 NULL锛熸垜濡備綍鎵嶈兘鍑嗙‘鎺掑簭鑰屼笉璁烘煇瀛楁鏄惁鍚玁ULL鍊硷紵
+4.10) 鍚勭瀛楃绫诲瀷涔嬮棿鏈変粈涔堜笉鍚岋紵
+4.11.1) 鎴戞庢牱鍒涘缓涓涓簭鍒楀彿鍨嬫垨鏄嚜鍔ㄩ掑鐨勫瓧娈碉紵
+
+4.11.2) 鎴戝浣曡幏寰椾竴涓彃鍏ョ殑搴忓垪鍙风殑鍊硷紵
+4.11.3) 鍚屾椂浣跨敤 currval() 浼氬鑷村拰鍏朵粬鐢ㄦ埛鐨勫啿绐佹儏鍐靛悧锛
+4.11.4) 涓轰粈涔堜笉鍦ㄤ簨鍔″紓甯镐腑姝㈠悗閲嶇敤搴忓垪鍙峰憿锛熶负浠涔堝湪搴忓垪鍙峰瓧娈电殑鍙栧间腑瀛樺湪闂存柇鍛紵
+4.12) 浠涔堟槸 OID锛熶粈涔堟槸 CTID 锛
+4.13) 涓轰粈涔堟垜鏀跺埌閿欒淇℃伅鈥ERROR: Memory exhausted in AllocSetAlloc()鈥濓紵
+
+4.14) 鎴戝浣曟墠鑳界煡閬撴墍杩愯鐨 PostgreSQL 鐨勭増鏈紵
+4.15) 鎴戝浣曞垱寤轰竴涓己鐪佸兼槸褰撳墠鏃堕棿鐨勫瓧娈碉紵
+4.16) 濡備綍鎵ц澶栬繛鎺ワ紙outer join锛夋煡璇紵
+4.17) 濡備綍鎵ц娑夊強澶氫釜鏁版嵁搴撶殑鏌ヨ锛
+4.18) 濡備綍璁╁嚱鏁拌繑鍥炲琛屾垨澶氬垪鏁版嵁锛
+4.19) 涓轰粈涔堟垜鍦ㄤ娇鐢≒L/PgSQL鍑芥暟瀛樺彇涓存椂琛ㄦ椂浼氭敹鍒伴敊璇俊鎭渞elation with OID ##### does not exist鈥濓紵
+
+4.20) 鐩墠鏈夊摢浜涙暟鎹鍒舵柟妗堝彲鐢紵
+4.21) 涓轰綍鏌ヨ缁撴灉鏄剧ず鐨勮〃鍚嶆垨鍒楀悕涓庢垜鐨勬煡璇㈣鍙ヤ腑鐨勪笉鍚岋紵涓轰綍澶у啓鐘舵佷笉鑳戒繚鐣欙紵
+
PostgreSQL 璇讳綔 Post-Gres-Q-L锛屾湁鏃跺欎篃绠绉颁负Postgres 銆傛兂鍚竴涓嬪叾鍙戦煶鐨勪汉鍛樺彲浠庤繖閲屼笅杞藉0闊虫枃浠讹細 + MP3 鏍煎紡 銆 +
+ +PostgreSQL 鏄潰鍚戠洰鏍囩殑鍏崇郴鏁版嵁搴撶郴缁燂紝瀹冨叿鏈変紶缁熷晢涓氭暟鎹簱绯荤粺鐨勬墍鏈夊姛鑳斤紝鍚屾椂鍙堝惈鏈夊皢鍦ㄤ笅涓浠 DBMS 绯荤粺鐨勪娇鐢ㄧ殑澧炲己鐗规с侾ostgreSQL 鏄嚜鐢卞厤璐圭殑锛屽苟涓旀墍鏈夋簮浠g爜閮藉彲浠ヨ幏寰椼 +
+ +PostgreSQL 鐨勫紑鍙戦槦浼嶄富瑕佷负蹇楁効鑰咃紝浠栦滑閬嶅竷涓栫晫鍚勫湴骞堕氳繃浜掕仈缃戣繘琛岃仈绯伙紝杩欐槸涓涓ぞ鍖哄紑鍙戦」鐩紝瀹冧笉琚换浣曞叕鍙告帶鍒躲 + 濡傛兂鍔犲叆寮鍙戦槦浼嶏紝璇峰弬瑙佸紑鍙戜汉鍛樺父瑙侀棶棰橈紙FAQ锛 + http://www.postgresql.org/files/documentation/faqs/FAQ_DEV.html + +
+ ++ 濡傛灉浣犲湪瀵绘壘PostgreSQL鐨勬帉闂ㄤ汉锛屾垨鏄粈涔堜腑澶鍛樹細锛屾垨鏄粈涔堟墍灞炲叕鍙革紝浣犲彧鑳芥斁寮冧簡---鍥犱负涓涓篃涓嶅瓨鍦紝浣嗘垜浠殑纭湁涓涓 + 鏍稿績濮斿憳浼氬拰CVS绠$悊缁勶紝浣嗚繖浜涘伐浣滅粍鐨勮绔嬩富瑕佹槸涓轰簡杩涜绠$悊宸ヤ綔鑰屼笉鏄PostgreSQL杩涜鐙崰寮忔帶鍒讹紝PostgreSQL椤圭洰鏄敱浠讳綍浜哄潎 + 鍙弬鍔犵殑寮鍙戜汉鍛樼ぞ鍖哄拰鎵鏈夌敤鎴锋帶鍒剁殑锛屼綘鎵闇瑕佸仛鐨勫氨鏄闃呴偖浠跺垪琛紝鍙備笌璁ㄨ鍗冲彲锛堣鍙備笌PostgreSQL鐨勫紑鍙戣瑙 + 寮鍙戜汉鍛樺父闂 (Developer's FAQ) 鑾峰彇淇℃伅锛夈 +
+ + +PostgreSQL鐨勫彂甯冮伒浠庣粡鍏哥殑BSD鐗堟潈銆傚畠鍏佽鐢ㄦ埛涓嶉檺鐩殑鍦颁娇鐢≒ostgreSQL锛岀敋鑷充綘鍙互閿鍞甈ostgreSQL鑰屼笉鍚簮浠g爜涔熷彲浠ワ紝鍞竴鐨勯檺鍒跺氨鏄綘涓嶈兘鍥犺蒋浠惰嚜韬棶棰樿屽悜鎴戜滑杩借瘔娉曞緥璐d换锛屽彟澶栧氨鏄姹傛墍鏈夌殑杞欢鎷疯礉涓』鍖呮嫭浠ヤ笅鐗堟潈澹版槑銆備笅闈㈠氨鏄垜浠墍浣跨敤鐨凚SD鐗堟潈澹版槑鍐呭锛
+ +PostgreSQL鏁版嵁搴撶鐞嗙郴缁
+ +閮ㄥ垎鐗堟潈锛坈锛1996-2005锛孭ostgreSQL 鍏ㄧ悆寮鍙戝皬缁勶紝閮ㄥ垎鐗堟潈锛坈锛1994-1996 鍔犲窞澶у钁d簨
+ +锛圥ortions copyright (c) 1996-2005,PostgreSQL Global Development Group Portions Copyright (c) 1994-6 Regents of the University of California锛
+ ++ 鍏佽涓轰换浣曠洰鐨勪娇鐢紝鎷疯礉锛屼慨鏀瑰拰鍒嗗彂杩欎釜杞欢鍜屽畠鐨勬枃妗h屼笉鏀跺彇浠讳綍璐圭敤锛 + 骞朵笖鏃犻』绛剧讲鍥犳鑰屼骇鐢熺殑璇佹槑锛屽墠鎻愭槸涓婇潰鐨勭増鏉冨0鏄庡拰鏈浠ュ強涓嬮潰涓ゆ鏂囧瓧鍑虹幇鍦ㄦ墍鏈夋嫹璐濅腑銆 + +
+ ++ 锛圥ermission 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.锛 +
+ ++ 鍦ㄤ换浣曟儏鍐典笅锛屽姞宸炲ぇ瀛﹂兘涓嶆壙鎷呭洜浣跨敤姝よ蒋浠跺強鍏舵枃妗h屽鑷寸殑瀵逛换浣曞綋浜嬩汉鐨勭洿鎺ョ殑锛 + 闂存帴鐨勶紝鐗规畩鐨勶紝闄勫姞鐨勬垨鑰呯浉浼磋岀敓鐨勬崯鍧忥紝鍖呮嫭鍒╃泭鎹熷け鐨勮矗浠伙紝鍗充娇鍔犲窞澶у宸茬粡寤鸿浜嗚繖浜涙崯澶辩殑鍙兘鎬ф椂涔熸槸濡傛銆 +
+ ++ 锛圛N 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.锛 +
+ + ++ 鍔犲窞澶у鏄庣‘鏀惧純浠讳綍淇濊瘉锛屽寘鎷絾涓嶅眬闄愪簬鏌愪竴鐗瑰畾鐢ㄩ旂殑鍟嗕笟鍜屽埄鐩婄殑闅愬惈淇濊瘉銆 + 杩欓噷鎻愪緵鐨勮繖浠借蒋浠舵槸鍩轰簬鈥滃綋浣滄槸鈥濈殑鍩虹鐨勶紝鍥犺屽姞宸炲ぇ瀛︽病鏈夎矗浠绘彁渚涚淮鎶わ紝鏀寔锛屾洿鏂帮紝澧炲己鎴栬呬慨鏀圭殑鏈嶅姟銆 +
+ +
+ 锛圱HE 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.锛
+
+
涓鑸鏉ワ紝浠讳綍鐜板湪瀵 UNIX 鍏煎鐨勬搷浣滅郴缁熶箣涓婇兘鑳借繍琛孭ostgreSQL 銆傚湪瀹夎鎸囧崡閲屽垪鍑轰簡鍙戝竷鏃剁粡杩囨槑纭祴璇曠殑骞冲彴銆
+ + +PostgreSQl涔熷彲浠ョ洿鎺ヨ繍琛屽湪鍩轰簬寰蒋Windows-NT鐨勬搷浣滅郴缁燂紝濡俉in2000 SP4锛學inXP 鍜 Win2003锛屽凡鍒朵綔瀹屾垚鐨勫畨瑁呭寘鍙粠 + http://pgfoundry.org/projects/pginstaller涓嬭浇锛屽熀浜嶮SDOS鐨刉indows鎿嶄綔绯荤粺 + 锛圵in95锛學in98锛學inMe锛夐渶瑕侀氳繃Cygwin妯℃嫙鐜杩愯PostgreSQL銆 +
+ ++ 鍚屾椂涔熸湁涓涓负Novell Netware 6寮鍙戠殑鐗堟湰鍙粠 http://forge.novell.com鑾峰彇锛屼负OS/2(eComStation)寮鍙戠殑鐗堟湰鍙粠 + http://hobbes.nmsu.edu/cgi-bin/h-search?sh=1&button=Search&key=postgreSQL&stype=all&sort=type&dir=%2F 涓嬭浇銆 + +
+ ++ 閫氳繃娴忚鍣ㄥ彲浠http://www.postgresql.org/ftp/涓嬭浇锛屼篃鍙氳繃FTP锛屼粠 + ftp://ftp.PostgreSQL.org/pub/绔欑偣涓嬭浇銆 +
+ +PostgreSQL 鏈鏂扮殑鐗堟湰鏄増鏈 8.2.1 銆
+ +鎴戜滑璁″垝姣忓勾鍙戝竷涓涓富瑕佸崌绾х増鏈紝姣忓嚑涓湀鍙戝竷涓涓皬鐗堟湰銆
+ + +PostgreSQL绀惧尯閫氳繃閭欢鍒楄〃涓哄叾澶у鏁扮敤鎴锋彁渚涘府鍔╋紝璁㈤槄閭欢鍒楄〃鐨勪富绔欑偣鏄 http://www.postgresql.org/community/lists/锛屼竴鑸儏鍐典笅锛屽厛鍔犲叆General 鎴 Bug閭欢鍒楄〃鏄竴涓緝濂界殑寮濮嬨 +
+ ++ 涓昏鐨処RC棰戦亾鏄湪FreeNode(irc.freenode.net)鐨#postgresql锛屼负浜嗚繛涓婃棰戦亾锛屽彲浠ヤ娇鐢║NIX绋嬪簭irc锛屽叾鎸囦护鏍煎紡锛 + irc -c '#postgresql' "$USER" irc.freenode.net 锛屾垨鑰呬娇鐢ㄥ叾浠朓RC瀹㈡埛绔▼搴忋傚湪姝ょ綉缁滀腑杩樺瓨鍦ㄤ竴涓狿ostgreSQL鐨勮タ鐝墮棰戦亾(#postgersql-es)鍜屾硶璇閬 + (#postgresql-fr)銆傚悓鏍峰湴锛屽湪EFNET涓婁篃鏈変竴涓狿ostgreSQL鐨勪氦娴侀閬撱 +
+ ++ 鍙彁渚涘晢涓氭敮鎸佺殑鍏徃鍒楄〃鍙湪http://techdocs.postgresql.org/companies.php娴忚銆 + +
+ + + ++ 鍙闂 http://www.postgresql.org/support/submitbug锛屽~鍐橞ug涓婃姤琛ㄦ牸鍗冲彲锛屽悓鏍蜂篃鍙闂甪tp绔欑偣ftp://ftp.PostgreSQL.org/pub/ 妫鏌ユ湁鏃犳洿鏂扮殑PostgreSQL鐗堟湰鎴栬ˉ涓併 +
+ + ++閫氳繃浣跨敤Bug鎻愪氦琛ㄦ牸鎴栨槸鍙戝線PostgreSQL閭欢鍒楄〃鐨凚ug閫氬父浼氭湁浠ヤ笅涔嬩竴鍥炲锛 +
+ +PostgreSQL 鏀寔涓涓墿灞曠殑 SQL:2003 鐨勫瓙闆嗐傚弬闃呮垜浠殑TODO 鍒楄〃锛屼簡瑙e凡鐭ug鍒楄〃銆佹殏缂虹殑鍔熻兘鍜屽皢鏉ョ殑寮鍙戣鍒掋 + +
+ +瑕佹眰澧炲姞鏂板姛鑳界殑鐢宠閫氬父浼氭敹鍒颁互涓嬩箣涓鐨勫洖澶嶏細
+ ++PostgreSQL涓嶄娇鐢˙ug璺熻釜绯荤粺锛屽洜涓烘垜浠彂鐜板湪閭欢鍒楄〃涓洿鎺ュ洖澶嶄互鍙婁繚璇乀ODO浠诲姟鍒楄〃鎬绘槸澶勪簬鏈鏂扮姸鎬佺殑鏂瑰紡宸ヤ綔鏁堢巼浼氭洿楂樹竴浜涖備簨瀹炰笂锛孊ug涓嶄細鍦ㄦ垜浠殑杞欢涓瓨鍦ㄥ緢闀挎椂闂达紝 +瀵瑰奖鍝嶅緢澶氱敤鎴风殑Bug涔熸绘槸寰堝揩浼氳淇銆傚敮涓鑳芥壘鍒版墍鏈夋敼杩涖佹彁楂樺拰淇鐨勫湴鏂规槸CVS鐨勬棩蹇椾俊鎭紝鍗充娇鏄湪杞欢鏂扮増鏈殑鍙戝竷淇℃伅涓篃涓嶄細鍒楀嚭姣忎竴澶勭殑杞欢鏇存柊銆 +
+ + + +PostgreSQL鍖呭惈澶ч噺鐨勬枃妗o紝涓昏鏈夎缁嗙殑鍙傝冩墜鍐岋紝鎵嬪唽椤靛拰涓浜涚殑娴嬭瘯渚嬪瓙銆傚弬瑙 /doc 鐩綍锛堣瘧娉細搴斾负 $PGHOME/doc锛夈 + 浣犺繕鍙互鍦ㄧ嚎娴忚PostgreSQL鐨勬墜鍐岋紝鍏剁綉鍧鏄細http://www.PostgreSQL.org/docs銆 +
+ ++ 鏈変袱鏈叧浜嶱ostgreSQL鐨勪功鍦ㄧ嚎鎻愪緵锛屽湪 + http://www.PostgreSQL.org/docs/awbook.html + 鍜 http://www.commandprompt.com/ppbook/ 銆 + 涔熸湁澶ч噺鐨凱ostgreSQL涔︾睄鍙緵璐拱锛屽叾涓渶涓烘祦琛岀殑涓鏈槸鐢盞orry Douglas缂栧啓鐨勩傚湪 + http://techdocs.PostgreSQL.org/techdocs/bookreviews.php涓 + 涓婃湁澶ч噺鏈夊叧PostgreSQL涔︾睄鐨勭畝浠嬨 + 鍦 http://techdocs.PostgreSQL.org/涓婃敹闆嗕簡鏈夊叧PostgreSQL鐨勫ぇ閲忔妧鏈枃绔犮 + +
+ ++ 瀹㈡埛绔殑鍛戒护琛岀▼搴psql鏈変竴浜涗互 \d 寮澶寸殑鍛戒护锛屽彲鏄剧ず鍏充簬绫诲瀷锛屾搷浣滅锛屽嚱鏁帮紝鑱氬悎绛変俊鎭紝浣跨敤 \? 鍙互鏄剧ず鎵鏈夊彲鐢ㄧ殑鍛戒护銆 +
+ ++ 鎴戜滑鐨 web 绔欑偣鍖呭惈鏇村鐨勬枃妗c +
+ + + ++ 棣栧厛鑰冭檻涓婅堪鎻愬埌鐨勪笌PostgreSQL鐩稿叧鐨勪功绫嶏紝鍙﹀涓鏈槸Teach Yourself SQL in 21 Days, Second Edition锛屽叾璇︾粏浠嬬粛鐨勭綉鍧鏄 + http://members.tripod.com/er4ebus/sql/index.htm锛 + 鎴戜滑鐨勮澶氱敤鎴峰枩娆The Practical SQL Handbook锛 Bowman, Judith S. 缂栧啓锛孉ddison-Wesley鍏徃鍑虹増锛屽叾浠栫殑鍒欏枩娆 + The Complete Reference SQL, Groff 缂栧啓锛孧cGraw-Hill鍏徃鍑虹増銆 +
+ +鍦ㄤ笅鍒楃綉鍧涓婁篃鏈夊緢濂界殑鏁欑▼锛屼粬浠槸
++ 璇﹁ 寮鍙戜汉鍛樺父瑙侀棶棰 (Developer's FAQ) 銆 + +
+ + ++璇勪环杞欢鏈夊ソ鍑犵鏂规硶锛氬姛鑳斤紝鎬ц兘锛屽彲闈犳э紝鏀寔鍜屼环鏍笺 +
+ +PostgreSQL(缂虹渷鎯呭喌)鍙畨瑁呮湁C鍜屽唴宓屽紡C鐨勬帴鍙o紝鍏朵粬鐨勬帴鍙i兘鏄嫭绔嬬殑椤圭洰锛岃兘澶熷垎鍒笅杞斤紝杩欎簺鎺ュ彛椤圭洰鐙珛鐨勫ソ澶 + 鏄粬浠彲浠ユ湁鍚勮嚜鐨勫彂甯冭鍒掑拰鍚勮嚜鐙珛鐨勫紑鍙戠粍銆 +
++ 涓浜涚紪绋嬭瑷濡侾HP閮芥湁璁块棶PostgreSQL鐨勬帴鍙o紝Perl銆乀CL銆丳ython浠ュ強寰堝鍏朵粬璇█鐨勬帴鍙e湪 + http://gborg.postgresql.org缃戠珯涓婄殑Drivers/Interfaces灏忚妭鍙壘鍒帮紝 + 骞朵笖閫氳繃Internet寰堝鏄撴悳绱㈠埌銆 +
+ + + + ++ 涓涓粙缁嶄互鏁版嵁搴撲负鍚庡彴鐨勬尯涓嶉敊鐨勭珯鐐规槸锛http://www.webreview.com銆 +
++ 瀵逛簬 Web 闆嗘垚锛孭HP 鏄竴涓瀬濂界殑鎺ュ彛銆傚畠鍦http://www.php.net/銆 + +
++ 瀵逛簬澶嶆潅鐨勪换鍔★紝寰堝浜洪噰鐢 Perl 鎺ュ彛鍜 浣跨敤CGI.pm鐨凞BD::Pg 鎴 mod_perl 銆 +
+ + ++ 鍟嗕笟鐢ㄦ埛鎴栨槸寮婧愬紑鍙戜汉鍛樿兘鎵惧埌寰堝鐨勬湁鍏砅ostgreSQL鐨凣UI鍥惧舰宸ュ叿杞欢锛屽湪 PostgreSQL绀惧尯鏂囨。鏈変竴涓缁嗙殑鍒楄〃銆 +
+ + ++ 鍦ㄨ繍琛 configure 鏃跺姞涓 --prefix 閫夐」銆 +
+ + + ++ 缂虹渷鎯呭喌涓嬶紝PostgreSQL鍙厑璁告潵鑷湰鏈轰笖閫氳繃 unix 鍩熷鎺ュ瓧鎴朤CP/IP鏂瑰紡鐨勮繛鎺ャ + 浣犲彧鏈夊湪淇敼浜嗛厤缃枃浠postgresql.conf涓殑listen_addresses锛屼笖涔熷湪閰嶇疆鏂囦欢$PGDATA/pg_hba.conf涓墦寮浜 + 鍩轰簬杩滅▼鐢佃剳锛 host-based 锛夌殑韬唤璁よ瘉锛屽苟閲嶆柊鍚姩PostgreSQL锛屽惁鍒欏叾浠栫數鑴戞槸涓嶈兘涓庝綘鐨凱ostgreSQL鏈嶅姟鍣ㄨ繘琛岃繛鎺ョ殑銆 +
+ + ++ 鏈変笁涓富瑕佹柟闈㈠彲浠ユ彁鍗嘝ostgreSQL鐨勬綔鑳姐 +
+ +PostgreSQL 鏈夊緢澶氱被浼 log_*
鐨勬湇鍔″櫒閰嶇疆鍙橀噺鍙敤浜庢煡璇㈢殑鎵撳嵃鍜岃繘绋嬬粺璁★紝鑰岃繖浜涘伐浣滃璋冭瘯鍜屾ц兘娴嬭瘯寰堟湁甯姪銆
+
+ 杩欒〃绀轰綘宸茶揪鍒扮己鐪100涓苟鍙戝悗鍙拌繘绋嬫暟鐨勯檺鍒讹紝浣犻渶瑕侀氳繃淇敼postgresql.conf鏂囦欢涓殑max_connections鍊兼潵 + 澧炲姞postmaster鐨勫悗鍙板苟鍙戝鐞嗘暟锛屼慨鏀瑰悗闇閲嶆柊鍚姩postmaster銆 + +
+ + ++ PostgreSQL 寮鍙戠粍瀵规瘡娆″皬鐗堟湰鐨勫崌绾т富瑕佸彧鍋氫簡涓浜汢ug淇宸ヤ綔锛屽洜姝や粠 7.4.8 鍗囩骇鍒 7.4.9 涓嶉渶瑕 dump 鍜 restore锛屼粎闇瑕佸仠姝㈡暟鎹簱鏈嶅姟鍣紝瀹夎鏇存柊鍚庣殑杞欢鍖咃紝鐒跺悗閲嶅惎鏈嶅姟鍣ㄥ嵆鍙 +
++ 鎵鏈塒ostgreSQL鐨勭敤鎴峰簲璇ュ湪鏈鎺ヨ繎锛堜綘鎵浣跨敤鐨勪富鐗堟湰锛夌殑灏忔敼杩涚増鏈彂甯冨敖蹇崌绾с傚敖绠℃瘡娆″崌绾у彲鑳介兘鏈変竴鐐归闄╋紝PostgreSQL鐨勫皬鏀硅繘鐗堜粎浠呮槸璁捐鐢ㄦ潵淇涓浜汢ug鐨勶紝浠g爜鏀瑰姩杈冨皯锛屾墍浠ラ闄╄繕鏄緢灏忕殑銆侾ostgreSQL绀惧尯璁や负涓鑸儏鍐典笅涓嶅崌绾х殑椋庨櫓杩樻槸澶氫簬鍗囩骇鐨勩 +
++ 涓荤増鏈殑鍗囩骇锛堜緥濡備粠 7.3 鍒 7.4锛夐氬父浼氫慨鏀圭郴缁熻〃鍜屾暟鎹〃鐨勫唴閮ㄦ牸寮忋 + 杩欎簺鏀瑰彉涓鑸瘮杈冨鏉傦紝鍥犳鎴戜滑涓嶇淮鎸佹暟鎹枃浠剁殑鍚戝悗鍏煎鎬с傚洜姝や粠鑰佺増鏈腑杩涜鏁版嵁瀵煎嚭锛坉ump锛/鐒跺悗鍦ㄦ柊鐗堟湰涓繘琛屾暟鎹鍏ワ紙reload锛夊涓荤増鏈殑鍗囩骇鏄繀椤荤殑銆 + +
+ ++ 鐢变簬璁$畻鏈虹‖浠跺ぇ澶氭暟鏄吋瀹圭殑锛屼汉浠绘槸鍊惧悜浜庣浉淇℃墍鏈夎绠楁満纭欢璐ㄩ噺涔熸槸鐩稿悓鐨勩備簨瀹炰笂涓嶆槸锛 + ECC RAM锛堝甫濂囧伓鏍¢獙鐨勫唴瀛橈級锛孲CSI 锛堢‖鐩橈級鍜屼紭璐ㄧ殑涓绘澘姣斾竴浜涗究瀹滆揣瑕佹洿鍔犲彲闈犱笖鍏锋湁鏇村ソ鐨勬ц兘銆侾ostgreSQL鍑犱箮鍙互杩愯鍦ㄤ换浣曠‖浠朵笂锛 + 浣嗗鏋滃彲闈犳у拰鎬ц兘瀵逛綘鐨勭郴缁熷緢閲嶈锛屼綘灏遍渶瑕佸叏闈㈢殑鐮旂┒涓涓嬩綘鐨勭‖浠堕厤缃簡銆傚湪鎴戜滑鐨勯偖浠跺垪琛ㄤ笂涔熸湁鍏充簬 + 纭欢閰嶇疆鍜屾т环姣旂殑璁ㄨ銆 +
+ + ++ 濡傛灉浣犲彧鏄鎻愬彇鍑犺鏁版嵁锛屽苟涓斾綘鍦ㄦ墽琛屾煡璇腑鐭ラ亾纭垏鐨勮鏁帮紝浣犲彲浠ヤ娇鐢↙IMIT鍔熻兘銆 + 濡傛灉鏈変竴涓储寮曚笌 ORDER BY涓殑鏉′欢鍖归厤锛孭ostgreSQL 鍙兘灏卞彧澶勭悊瑕佹眰鐨勫ご鍑犳潯璁板綍锛 + 锛堝惁鍒欏皢瀵规暣涓煡璇㈣繘琛屽鐞嗙洿鍒扮敓鎴愰渶瑕佺殑琛岋級銆傚鏋滃湪鎵ц鏌ヨ鍔熻兘鏃朵笉鐭ラ亾纭垏鐨勮褰曟暟锛 + 鍙娇鐢ㄦ父鏍(cursor)鍜孎ETCH鍔熻兘銆 +
++ 鍙娇鐢ㄤ互涓嬫柟娉曟彁鍙栦竴琛岄殢鏈鸿褰曠殑锛 +
++ SELECT cols + FROM tab + ORDER BY random() + LIMIT 1 ; + ++ + + +
+ 鍦psql涓娇鐢 \dt 鍛戒护鏉ユ樉绀烘暟鎹〃鐨勫畾涔夛紝瑕佷簡瑙psql涓殑瀹屾暣鍛戒护鍒楄〃鍙娇鐢╘? 锛屽彟澶栵紝浣犱篃鍙互闃呰 psql 鐨勬簮浠g爜 + 鏂囦欢pgsql/src/bin/psql/describe.c锛屽畠鍖呮嫭涓虹敓鎴psql鍙嶆枩鏉犲懡浠ょ殑杈撳嚭鐨勬墍鏈 SQL 鍛戒护銆備綘杩樺彲浠ュ甫 -E 閫夐」鍚姩 psql锛 + 杩欐牱瀹冨皢鎵撳嵃鍑轰綘鍦psql涓墍缁欏嚭鐨勫懡浠ゆ墽琛屾椂鐨勫唴閮ㄥ疄闄呬娇鐢ㄧ殑SQL鏌ヨ璇彞銆侾ostgreSQL涔熸彁渚涗簡涓涓吋瀹筍QL鐨処NFORMATION SCHEMA鎺ュ彛锛 + 浣犲彲浠ヤ粠杩欓噷鑾峰彇鍏充簬鏁版嵁搴撶殑淇℃伅銆 + +
++ 鍦ㄧ郴缁熶腑涔熸湁涓浜涗互pg_ 鎵撳ご鐨勭郴缁熻〃涔熸弿杩颁簡琛ㄧ殑瀹氫箟銆 +
++ 浣跨敤 psql -l 鎸囦护鍙互鍒楀嚭鎵鏈夌殑鏁版嵁搴撱 +
++ 涔熷彲浠ユ祻瑙堜竴涓 pgsql/src/tutorial/syscat.source鏂囦欢锛屽畠鍒椾妇浜嗗緢澶氬彲浠庢暟鎹簱绯荤粺琛ㄤ腑鑾峰彇淇℃伅鐨凷ELECT璇硶銆 + +
+ + ++ 鍦8.0鐗堟湰閲屾洿鏀逛竴涓瓧娈电殑鏁版嵁绫诲瀷寰堝鏄擄紝鍙娇鐢 ALTER TABLE ALTER COLUMN TYPE 銆 +
++ 鍦ㄤ互鍓嶇殑鐗堟湰涓紝鍙互杩欐牱鍋氾細 +
++ BEGIN; + ALTER TABLE tab ADD COLUMN new_col new_data_type; + UPDATE tab SET new_col = CAST(old_col AS new_data_type); + ALTER TABLE tab DROP COLUMN old_col; + COMMIT; + ++
+ 浣犵劧鍚庡彲浠ヤ娇鐢VACUUM FULL tab 鎸囦护鏉ヤ娇绯荤粺鏀跺洖鏃犳晥鏁版嵁鎵鍗犵敤鐨勭┖闂淬 +
+ ++ 涓嬮潰鏄竴浜涢檺鍒讹細 +
+++ + ++ + +
++ 鍗曚釜鏁版嵁搴撴渶澶у昂瀵革紵 鏃犻檺鍒讹紙宸插瓨鍦ㄦ湁 32TB 鐨勬暟鎹簱锛 + 鍗曚釜琛ㄧ殑鏈澶у昂瀵革紵 32 TB + 涓琛岃褰曠殑鏈澶у昂瀵革紵 1.6 TB + + 涓涓瓧娈电殑鏈澶у昂瀵? 1 GB + 涓涓〃閲屾渶澶ц鏁帮紵 鏃犻檺鍒 + 涓涓〃閲屾渶澶у垪鏁帮紵 250-1600 锛堜笌鍒楃被鍨嬫湁鍏筹級 + + 涓涓〃閲岀殑鏈澶х储寮曟暟閲忥紵 鏃犻檺鍒
+ 褰撶劧锛屽疄闄呬笂娌℃湁鐪熸鐨勬棤闄愬埗锛岃繕鏄鍙楀彲鐢ㄧ鐩樼┖闂淬佸彲鐢ㄥ唴瀛/浜ゆ崲鍖虹殑鍒剁害銆 + 浜嬪疄涓婏紝褰撲笂杩拌繖浜涙暟鍊煎彉寰楀紓甯稿湴澶ф椂锛岀郴缁熸ц兘涔熶細鍙楀緢澶у奖鍝嶃 +
+ ++ 鍗曡〃鐨勬渶澶уぇ灏 32 TB 涓嶉渶瑕佹搷浣滅郴缁熷鍗曚釜鏂囦欢涔熼渶杩欎箞澶х殑鏀寔銆傚ぇ琛ㄧ敤澶氫釜 1 GB 鐨勬枃浠跺瓨鍌紝鍥犳鏂囦欢绯荤粺澶у皬鐨勯檺鍒舵槸涓嶉噸瑕佺殑銆 +
++ 濡傛灉缂虹渷鐨勫潡澶у皬澧為暱鍒 32K 锛屾渶澶х殑鍗曡〃澶у皬鍜屾渶澶у垪鏁拌繕鍙互澧炲姞鍒板洓鍊嶃 +
++ 鏈変竴涓檺鍒跺氨鏄笉鑳藉澶у皬澶氫簬2000瀛楄妭鐨勫垪鍒涘缓绱㈠紩銆傚垢杩愬湴鏄繖鏍风殑绱㈠紩寰堝皯鐢ㄥ埌銆傞氳繃瀵瑰瀛楄妭鍒楃殑鍐呭杩涜MD5鍝堢█杩愮畻缁撴灉杩涜鍑芥暟绱㈠紩鍙鍒楃殑鍞竴鎬у緱鍒颁繚璇侊紝 + 骞朵笖鍏ㄦ枃妫绱㈠厑璁稿鍒椾腑鐨勫崟璇嶈繘琛屾悳绱€ +
+ + ++ 涓涓 Postgres 鏁版嵁搴擄紙瀛樺偍涓涓枃鏈枃浠讹級鎵鍗犵敤鐨勭┖闂存渶澶氬彲鑳介渶瑕佺浉褰撲簬杩欎釜鏂囨湰鏂囦欢鑷韩澶у皬5鍊嶇殑纾佺洏绌洪棿銆 +
++ 渚嬪锛屽亣璁炬湁涓涓 100,000 琛岀殑鏂囦欢锛屾瘡琛屾湁涓涓暣鏁板拰涓涓枃鏈弿杩般 + 鍋囪鏂囨湰涓茬殑骞冲潎闀垮害涓20瀛楄妭銆傛枃鏈枃浠跺崰鐢 2.8 MB銆傚瓨鏀捐繖浜涙暟鎹殑PostgreSQL鏁版嵁搴撴枃浠跺ぇ绾︽槸 6.4 MB: +
++ 28 瀛楄妭: 姣忚鐨勫ご锛堝ぇ绾﹀硷級 + 24 瀛楄妭: 涓涓暣鏁板瀷瀛楁鍜屼竴涓枃鏈瀷瀛楁 + + 4 瀛楄妭: 椤甸潰鍐呮寚鍚戝厓缁勭殑鎸囬拡 + ---------------------------------------- + 56 瀛楄妭姣忚 + + PostgreSQL 鏁版嵁椤电殑澶у皬鏄 8192 瀛楄妭 (8 KB)锛屽垯锛 + + 8192 瀛楄妭姣忛〉 + ------------------- = 146 琛/鏁版嵁椤碉紙鍚戜笅鍙栨暣锛 + 56 瀛楄妭姣忚 + + 100000 鏁版嵁琛 + -------------------- = 685 鏁版嵁椤碉紙鍚戜笂鍙栨暣锛 + 146 琛/鏁版嵁椤 + + 685 鏁版嵁椤 * 8192 瀛楄妭/椤 = 5,611,520 瀛楄妭锛5.6 MB锛 ++ + +
+ 绱㈠紩涓嶉渶瑕佽繖涔堝鐨勯澶栨秷鑰楋紝浣嗕篃纭疄鍖呮嫭琚储寮曠殑鏁版嵁锛屽洜姝ゅ畠浠篃鍙兘寰堝ぇ銆 +
++ 绌哄NULL瀛樻斁鍦ㄤ綅鍥句腑锛屽洜姝ゅ崰鐢ㄥ緢灏戠殑绌洪棿銆 +
+ ++ 骞堕潪姣忎釜鏌ヨ閮戒細鑷姩浣跨敤绱㈠紩銆傚彧鏈夊湪琛ㄧ殑澶у皬瓒呰繃涓涓渶灏忓硷紝骞朵笖鏌ヨ鍙細閫変腑琛ㄤ腑杈冨皬姣斾緥鐨勮褰曟椂鎵嶄細閲囩敤绱㈠紩銆 + 杩欐槸鍥犱负绱㈠紩鎵弿寮曡捣鐨勯殢鍗崇鐩樺瓨鍙栧彲鑳芥瘮鐩存帴鍦拌鍙栬〃锛堥『搴忔壂鎻忥級鏇存參銆 + +
++ 涓轰簡鍒ゆ柇鏄惁浣跨敤绱㈠紩锛孭ostgreSQL蹇呴』鑾峰緱鏈夊叧琛ㄧ殑缁熻鍊笺傝繖浜涚粺璁″煎彲浠ヤ娇鐢 VACUUM ANALYZE锛屾垨 ANALYZE 鑾峰緱銆 + 浣跨敤缁熻鍊硷紝浼樺寲鍣ㄧ煡閬撹〃涓湁澶氬皯琛岋紝灏辫兘澶熸洿濂藉湴鍒ゆ柇鏄惁鍒╃敤绱㈠紩銆 + 缁熻鍊煎纭畾浼樺寲鐨勮繛鎺ラ『搴忓拰杩炴帴鏂规硶涔熷緢鏈夌敤銆傚湪琛ㄧ殑鍐呭鍙戠敓鍙樺寲鏃讹紝搴斿畾鏈熻繘琛岀粺璁″肩殑鏇存柊鏀堕泦銆 +
++ 绱㈠紩閫氬父涓嶇敤浜 ORDER BY 鎴栨墽琛岃繛鎺ャ傚涓涓ぇ琛ㄧ殑涓娆¢『搴忔壂鎻忓啀鍋氫竴娆℃帓搴忛氬父姣旂储寮曟壂鎻忚蹇傜劧鑰岋紝濡傛灉灏 LIMIT 鍜 ORDER BY + 缁撳悎鍦ㄤ竴璧蜂娇鐢ㄧ殑璇濓紝閫氬父灏嗕細浣跨敤绱㈠紩锛屽洜涓鸿繖鏃朵粎杩斿洖琛ㄤ腑鐨勪竴灏忛儴鍒嗚褰曘 +
+
+ 濡傛灉浣犵‘淇ostgreSQL鐨勪紭鍖栧櫒浣跨敤椤哄簭鎵弿鏄笉姝g‘鐨勶紝浣犲彲浠ヤ娇鐢SET enable_seqscan TO 'off'
鎸囦护鏉ュ叧闂『搴忔壂鎻忥紝
+ 鐒跺悗鍐嶆杩愯鏌ヨ锛屼綘灏卞彲浠ョ湅鍑轰娇鐢ㄤ竴涓储寮曟壂鎻忔槸鍚︾‘瀹炶蹇竴浜涖
+
+ + 褰撲娇鐢ㄩ氶厤绗︽搷浣滐紝渚嬪 LIKE 鎴 ~ 鏃讹紝绱㈠紩鍙兘鍦ㄧ壒瀹氱殑鎯呭喌涓嬩娇鐢細 +
+text_pattern_ops
绱㈠紩鏉ョ敤浜LIKE鐨勭储寮曘
+ + 鍦8.0涔嬪墠鐨勭増鏈腑锛岄櫎闈炶鏌ヨ鐨勬暟鎹被鍨嬪拰绱㈠紩鐨勬暟鎹被鍨嬬浉鍖归厤锛屽惁鍒欑储寮曠粡甯告槸鏈鐢ㄥ埌锛岀壒鍒槸瀵筰nt2,int8鍜屾暟鍊煎瀷鐨勭储寮曘 +
+ +鍙傝 EXPLAIN 鎵嬪唽椤点
+ ++ 鎿嶄綔绗 ~ 澶勭悊姝e垯琛ㄨ揪寮忓尮閰嶏紝鑰 ~* 澶勭悊澶у皬鍐欐棤鍏崇殑姝e垯琛ㄨ揪寮忓尮閰嶃傚ぇ灏忓啓鏃犲叧鐨 LIKE 鍙樼鎴愪负 ILIKE銆 + +
++ 澶у皬鍐欐棤鍏崇殑绛夊紡姣旇緝閫氬父鍐欏仛锛 +
++ SELECT * + FROM tab + WHERE lower(col) = 'abc'; ++ +
+ 杩欐牱灏嗕笉浼氫娇鐢ㄦ爣鍑嗙殑绱㈠紩銆備絾鏄彲浠ュ垱寤轰竴涓湪杩欑鎯呭喌涓嬩娇鐢ㄧ殑琛ㄨ揪寮忕储寮: +
++ CREATE INDEX tabindex ON tab (lower(col)); + ++
+ 濡傛灉涓婅堪绱㈠紩鍦ㄥ垱寤烘椂鍔犲叆UNIQUE绾︽潫锛岃櫧鐒剁储寮曞瓧娈佃嚜韬唴瀹瑰彲浠ュ瓨鍌ㄥぇ灏忓啓涓嶉檺鐨勫唴瀹癸紝浣嗗鏋滄湁UNIQUE绾︽潫鍚庯紝杩欎簺鍐呭涓嶈兘浠呬粎鏄ぇ灏忓啓涓嶅悓锛堝惁鍒欎細閫犳垚鍐茬獊锛夈備负浜嗕繚璇佷笉鍙戠敓杩欑鎯呭喌锛屽彲浠ヤ娇鐢–HECK绾︽潫鏉′欢鎴栨槸瑙﹀彂鍣ㄥ湪褰曞叆鏃惰繘琛岄檺鍒躲 +
+ + ++ + 鐢 IS NULL 鍜 IS NOT NULL 娴嬭瘯杩欎釜瀛楁锛屽叿浣撴柟娉曞涓嬶細 +
+SELECT * + FROM tab + WHERE col IS NULL; ++ +
涓轰簡鑳藉鍚 NULL瀛楁鎺掑簭锛屽彲鍦 ORDER BY 鏉′欢涓娇鐢 IS NULL鍜 + IS NOT NULL 淇グ绗︼紝鏉′欢涓虹湡 true 灏嗘瘮鏉′欢涓哄亣false 鎺掑湪鍓嶉潰锛屼笅闈㈢殑渚嬪瓙灏变細灏嗗惈 + NULL 鐨勮褰曟帓鍦ㄧ粨鏋滅殑涓婇潰閮ㄥ垎锛 + +
+SELECT * + FROM tab + ORDER BY (col IS NOT NULL) ++ +
++ ++ +
++ + 绫诲瀷 鍐呴儴鍚嶇О 璇存槑 + VARCHAR(n) varchar 鎸囧畾浜嗘渶澶ч暱搴︼紝鍙橀暱瀛楃涓诧紝涓嶈冻瀹氫箟闀垮害鐨勯儴鍒嗕笉琛ラ綈 + CHAR(n) bpchar 瀹氶暱瀛楃涓诧紝瀹為檯鏁版嵁涓嶈冻瀹氫箟闀垮害鏃讹紝浠ョ┖鏍艰ˉ榻 + TEXT text 娌℃湁鐗瑰埆鐨勪笂闄愰檺鍒讹紙浠呭彈琛岀殑鏈澶ч暱搴﹂檺鍒讹級 + + BYTEA bytea 鍙橀暱瀛楄妭搴忓垪锛堜娇鐢∟ULL瀛楃涔熸槸鍏佽鐨勶級 + + "char" char 鍗曚釜瀛楃
+ 鍦ㄧ郴缁熻〃鍜屽湪涓浜涢敊璇俊鎭噷浣犲皢鐪嬪埌鍐呴儴鍚嶇О銆 +
++ 涓婇潰鎵鍒楃殑鍓嶅洓绉嶇被鍨嬫槸"varlena"锛堝彉闀匡級绫诲瀷锛堜篃灏辨槸璇达紝寮澶寸殑鍥涗釜瀛楄妭鏄暱搴︼紝鍚庨潰鎵嶆槸鏁版嵁锛夈 + 浜庢槸瀹為檯鍗犵敤鐨勭┖闂存瘮澹版槑鐨勫ぇ灏忚澶氫竴浜涖 + 鐒惰岃繖浜涚被鍨嬪瀹氫箟寰堥暱鏃堕兘鍙互琚帇缂╁瓨鍌紝鍥犳纾佺洏绌洪棿涔熷彲鑳芥瘮棰勬兂鐨勮灏戙 + +
++ VARCHAR(n) 鍦ㄥ瓨鍌ㄩ檺鍒朵簡鏈澶ч暱搴︾殑鍙橀暱瀛楃涓叉槸鏈濂界殑銆 + TEXT 閫傜敤浜庡瓨鍌ㄦ渶澶у彲杈 1G宸﹀彸浣嗘湭瀹氫箟闄愬埗闀垮害鐨勫瓧绗︿覆銆 +
++ CHAR(n) 鏈閫傚悎浜庡瓨鍌ㄩ暱搴︾浉鍚岀殑瀛楃涓层 CHAR(n)浼氭牴鎹墍缁欏畾鐨勫瓧娈甸暱搴︿互绌烘牸琛ヨ冻锛堜笉瓒崇殑瀛楁鍐呭锛夛紝 + 鑰 VARCHAR(n) 鍙瓨鍌ㄦ墍缁欏畾鐨勬暟鎹唴瀹广 + BYTEA 鐢ㄤ簬瀛樺偍浜岃繘鍒舵暟鎹紝灏ゅ叾鏄寘鍚 NULL 瀛楄妭鐨勫笺傝繖浜涚被鍨嬪叿鏈夊樊涓嶅鐨勬ц兘銆 + +
+ + + +PostgreSQL 鏀寔 SERIAL 鏁版嵁绫诲瀷銆傦紙瀛楁瀹氫箟涓篠ERIAL鍚庯級灏嗚嚜鍔ㄥ垱寤轰竴涓簭鍒楃敓鎴愬櫒锛屼緥濡傦細 +
++ CREATE TABLE person ( + id SERIAL, + name TEXT + ); ++
+ 浼氳嚜鍔ㄨ浆鎹负浠ヤ笅SQL璇彞锛 +
+ ++ CREATE SEQUENCE person_id_seq; + CREATE TABLE person ( + id INT4 NOT NULL DEFAULT nextval('person_id_seq'), + name TEXT + ); ++
+ 鍙傝 create_sequence 鎵嬪唽椤佃幏鍙栧叧浜庡簭鍒楃敓鎴愬櫒鐨勬洿澶氫俊鎭 +
+ + ++ 涓绉嶆柟娉曟槸鍦ㄦ彃鍏ヤ箣鍓嶅厛鐢ㄥ嚱鏁 nextval() 浠庡簭鍒楀璞¢噷妫绱㈠嚭涓嬩竴涓 SERIAL 鍊硷紝鐒跺悗鍐嶇敤姝ゅ肩簿纭湴鎻掑叆銆備娇鐢 + 4.11.1 閲岀殑渚嬭〃锛屽彲鐢ㄤ吉鐮佽繖鏍锋弿杩帮細 + +
++ new_id = execute("SELECT nextval('person_id_seq')"); + execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')"); ++
+ 杩欐牱杩樿兘鍦ㄥ叾浠栨煡璇腑浣跨敤瀛樻斁鍦 new_id 閲岀殑鏂板硷紙渚嬪锛屼綔涓哄弬鐓 person 琛ㄧ殑澶栭敭锛夈 + 娉ㄦ剰鑷姩鍒涘缓鐨 SEQUENCE 瀵硅薄鐨勫悕绉板皢浼氭槸 <table>_<serialcolumn>_seq锛 + 杩欓噷 table 鍜 serialcolumn 鍒嗗埆鏄綘鐨勮〃鐨勫悕绉板拰浣犵殑 SERIAL 瀛楁鐨勫悕绉般 +
++ 绫讳技鐨勶紝鍦 SERIAL 瀵硅薄缂虹渷鎻掑叆鍚庝綘鍙互鐢ㄥ嚱鏁 currval() 妫绱㈠垰璧嬪肩殑 SERIAL 鍊硷紝渚嬪锛 + +
++ execute("INSERT INTO person (name) VALUES ('Blaise Pascal')"); + new_id = execute("SELECT currval('person_id_seq')"); ++ +
+ 涓嶄細銆currval() 杩斿洖鐨勬槸浣犳湰娆′細璇濊繘绋嬫墍璧嬬殑鍊艰屼笉鏄墍鏈夌敤鎴风殑褰撳墠鍊笺
+
+
+ 涓轰簡鎻愰珮骞跺彂鎬э紝搴忓垪鍙峰湪闇瑕佺殑鏃跺欒祴浜堟鍦ㄨ繍琛岀殑浜嬪姟锛屽苟涓斿湪浜嬪姟缁撴潫涔嬪墠涓嶈繘琛岄攣瀹氾紝 + 杩欏氨浼氬鑷村紓甯镐腑姝㈢殑浜嬪姟鍚庯紝搴忓垪鍙蜂細鍑虹幇闂撮殧銆 +
+ +PostgreSQL 閲屽垱寤虹殑姣忎竴琛岃褰曢兘浼氳幏寰椾竴涓敮涓鐨OID锛岄櫎闈炲湪鍒涘缓琛ㄦ椂浣跨敤WITHOUT OIDS閫夐」銆 + OID鍒涘缓鏃朵細鑷姩鐢熸垚涓涓4瀛楄妭鐨勬暣鏁帮紝鎵鏈 OID 鍦ㄧ浉搴擯ostgreSQL鏈嶅姟鍣ㄤ腑鍧囨槸鍞竴鐨勩 鐒惰岋紝瀹冨湪瓒呰繃40浜挎椂灏嗘孩鍑猴紝 + OID姝ゅ悗浼氬嚭鐜伴噸澶嶃侾ostgreSQL 鍦ㄥ畠鐨勫唴閮ㄧ郴缁熻〃閲屼娇鐢 OID 鍦ㄨ〃涔嬮棿寤虹珛鑱旂郴銆 +
++ 鍦ㄧ敤鎴风殑鏁版嵁琛ㄤ腑锛屾渶濂芥槸浣跨敤SERIAl鏉ヤ唬鏇OID + + 鍥犱负SERIAL鍙淇濊瘉鍦ㄥ崟涓〃涓殑鏁板兼槸鍞竴鐨勫氨鍙互浜嗭紝杩欐牱瀹冩孩鍑虹殑鍙兘鎬у氨闈炲父灏忎簡锛 + SERIAL8鍙敤鏉ヤ繚瀛8瀛楄妭鐨勫簭鍒楁暟鍊笺 +
+ ++ CTID 鐢ㄤ簬鏍囪瘑甯︾潃鏁版嵁鍧楋紙鍦板潃锛夊拰锛堝潡鍐咃級鍋忕Щ鐨勭壒瀹氱殑鐗╃悊琛屻 + CTID 鍦ㄨ褰曡鏇存敼鎴栭噸杞藉悗鍙戠敓鏀瑰彉銆傜储寮曟暟鎹娇鐢ㄥ畠浠寚鍚戠墿鐞嗚銆 +
+ + + ++ 杩欏緢鍙兘鏄郴缁熺殑铏氭嫙鍐呭瓨鐢ㄥ厜浜嗭紝鎴栬呭唴鏍稿鏌愪簺璧勬簮鏈夎緝浣庣殑闄愬埗鍊笺傚湪鍚姩 postmaster 涔嬪墠璇曡瘯涓嬮潰鐨勫懡浠わ細 +
++ ulimit -d 262144 + limit datasize 256m ++
+ 鍙栧喅浜庝綘鐢ㄧ殑 shell锛屼笂闈㈠懡浠ゅ彧鏈変竴鏉¤兘鎴愬姛锛屼絾鏄畠灏嗘妸浣犵殑杩涚▼鏁版嵁娈甸檺鍒惰寰楁瘮杈冮珮锛 + 鍥犺屼篃璁歌兘璁╂煡璇㈠畬鎴愩傝繖鏉″懡浠ゅ簲鐢ㄤ簬褰撳墠杩涚▼锛屼互鍙婃墍鏈夊湪杩欐潯鍛戒护杩愯鍚庡垱寤虹殑瀛愯繘绋嬨 + 濡傛灉浣犳槸鍦ㄨ繍琛孲QL瀹㈡埛绔椂鍥犱负鍚庡彴杩斿洖浜嗗お澶氱殑鏁版嵁鑰屽嚭鐜伴棶棰橈紝璇峰湪杩愯瀹㈡埛绔箣鍓嶆墽琛屼笂杩板懡浠ゃ + +
+ +
+ 浠 psql 閲岋紝杈撳叆 SELECT version();
鎸囦护銆
+
+ 浣跨敤 CURRENT_TIMESTAMP锛 + +
++ CREATE TABLE test (x int, modtime TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); ++ + +
PostgreSQL 閲囩敤鏍囧噯鐨 SQL 璇硶鏀寔澶栬繛鎺ャ傝繖閲屾槸涓や釜渚嬪瓙锛
++ 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 涓病鏈夊尮閰嶇殑琛岋級銆 + 鍙砙澶朷杩炴帴锛圧IGHT OUTER JOIN锛夊皢杩斿洖 t2 涓湭杩炴帴鐨勮銆 + 瀹屽叏澶栬繛鎺ワ紙FULL OUTER JOIN锛夊皢杩斿洖 t1 鍜 t2 涓湭杩炴帴鐨勮銆 + 鍏抽敭瀛 OUTER 鍦ㄥ乏[澶朷杩炴帴銆佸彸[澶朷杩炴帴鍜屽畬鍏╗澶朷杩炴帴涓槸鍙夌殑锛屾櫘閫氳繛鎺ヨ绉颁负鍐呰繛鎺ワ紙INNER JOIN锛夈 +
+ + ++ 娌℃湁鍔炴硶鏌ヨ褰撳墠鏁版嵁搴撲箣澶栫殑鏁版嵁搴撱 + 鍥犱负PostgreSQL瑕佸姞杞戒笌鏁版嵁搴撶浉鍏崇殑绯荤粺鐩綍锛堢郴缁熻〃锛夛紝鍥犳璺ㄦ暟鎹簱鐨勬煡璇㈠浣曟墽琛屾槸涓嶅畾鐨勩 +
+ ++ 闄勫姞澧炲兼ā鍧梒ontrib/dblink鍏佽閲囩敤鍑芥暟璋冪敤瀹炵幇璺ㄥ簱鏌ヨ銆傚綋鐒剁敤鎴蜂篃鍙互鍚屾椂杩炴帴鍒颁笉鍚岀殑鏁版嵁搴撴墽琛屾煡璇㈢劧鍚庡湪瀹㈡埛绔悎骞剁粨鏋溿 +
+ ++ 鍦ㄥ嚱鏁颁腑杩斿洖鏁版嵁璁板綍闆嗙殑鍔熻兘鏄緢瀹规槗浣跨敤鐨勶紝璇︽儏鍙傝锛 + http://techdocs.postgresql.org/guides/SetReturningFunctions +
+ ++ PL/PgSQL浼氱紦瀛樺嚱鏁扮殑鑴氭湰鍐呭锛岀敱姝ゅ甫鏉ョ殑涓涓笉濂界殑鍓綔鐢ㄦ槸鑻ヤ竴涓 PL/PgSQL + 鍑芥暟璁块棶浜嗕竴涓复鏃惰〃锛岀劧鍚庤琛ㄨ鍒犻櫎骞堕噸寤轰簡锛屽垯鍐嶆璋冪敤璇ュ嚱鏁板皢澶辫触锛 + 鍥犱负缂撳瓨鐨勫嚱鏁板唴瀹逛粛鐒舵寚鍚戞棫鐨勪复鏃惰〃銆傝В鍐崇殑鏂规硶鏄湪 PL/PgSQL 涓敤EXECUTE + 瀵逛复鏃惰〃杩涜璁块棶銆傝繖鏍蜂細淇濊瘉鏌ヨ鍦ㄦ墽琛屽墠鎬讳細琚噸鏂拌В鏋愩 +
+ ++ 鈥滃鍒垛濆彧鏄竴涓湳璇紝鏈夊ソ鍑犵澶嶅埗鎶鏈彲鐢紝姣忕閮芥湁浼樼偣鍜岀己鐐癸細 +
++ + 涓/浠庡鍒舵柟寮忔槸鍏佽涓涓富鏈嶅姟鍣ㄦ帴鍙楄/鍐欑殑鐢宠锛岃屽涓粠鏈嶅姟鍣ㄥ彧鑳芥帴鍙楄/SELECT鏌ヨ鐨勭敵璇凤紝 + 鐩墠鏈娴佽涓斿厤璐圭殑涓/浠嶱ostgreSQL澶嶅埗鏂规鏄 + Slony-I 銆 +
++ 澶氫釜涓绘湇鍔″櫒鐨勫鍒舵柟寮忓厑璁稿皢璇/鍐欑殑鐢宠鍙戦佺粰澶氬彴鐨勮绠楁満锛岃繖绉嶆柟寮忕敱浜庨渶瑕佸湪澶氬彴鏈嶅姟鍣ㄤ箣闂村悓姝ユ暟鎹彉鍔 + 鍙兘浼氬甫鏉ヨ緝涓ラ噸鐨勬ц兘鎹熷け锛Pgcluster鏄洰鍓嶈繖绉嶆柟妗 + 涓渶濂界殑锛岃屼笖杩樺彲浠ュ厤璐逛笅杞姐 +
++ 涔熸湁涓浜涘晢涓氶渶浠樿垂鍜屽熀浜庣‖浠剁殑鏁版嵁澶嶅埗鏂规锛屾敮鎸佷笂杩板悇绉嶅鍒舵ā鍨嬨 +
+ + ++ 鏈甯歌鐨勫師鍥犳槸鍦ㄥ垱寤鸿〃鏃跺琛ㄥ悕鎴栨槸鍒楀悕浣跨敤浜嗗弻寮曞彿鈥溾濓紝褰撲娇鐢ㄤ簡鍙屽紩鍙峰悗锛岃〃鍚嶆垨鍒楀悕锛堢О涓烘爣璇嗙锛夊瓨鍌ㄦ椂鏄尯鍒 +澶у皬鍐欑殑锛 + 杩欐剰璋撶潃浣犲湪鏌ヨ鏃惰〃鍚嶆垨鍒楀悕涔熷簲浣跨敤鍙屽紩鍙凤紝涓浜涘伐鍏疯蒋浠讹紝鍍弍gAdmin浼氬湪鍙戝嚭鍒涘缓琛ㄧ殑鎸囦护鏃惰嚜鍔ㄥ湴鍦ㄦ瘡涓爣璇嗙涓婂姞鍙屽紩鍙枫 + 鍥犳锛屼负浜嗘爣璇嗙鐨勭粺涓锛屼綘搴旇锛 +
+