目录搜索
前言何为PostgreSQL?PostgreSQL简史格式约定更多信息臭虫汇报指导I. 教程章1. 从头开始1.1. 安装1.2. 体系基本概念1.3. 创建一个数据库1.4. 访问数据库章2. SQL语言2.1. 介绍2.2. 概念2.3. 创建新表2.4. 向表中添加行2.5. 查询一个表2.6. 表间链接2.7. 聚集函数2.8. 更新2.9. 删除章3. 高级特性3.1. 介绍3.2. 视图3.3. 外键3.4. 事务3.5. 窗口函数3.6. 继承3.7. 结论II. SQL语言章4. SQL语法4.1. 词法结构4.2. 值表达式4.3. 调用函数章5. 数据定义5.1. 表的基本概念5.2. 缺省值5.3. 约束5.4. 系统字段5.5. 修改表5.6. 权限5.7. 模式5.8. 继承5.9. 分区5.10. 其它数据库对象5.11. 依赖性跟踪章 6. 数据操作6.1. 插入数据6.2. 更新数据6.3. 删除数据章7. 查询7.1. 概述7.2. 表表达式7.3. 选择列表7.4. 组合查询7.5. 行排序7.6. LIMIT和OFFSET7.7. VALUES列表7.8. WITH的查询(公用表表达式)章8. 数据类型8.1. 数值类型8.2. 货币类型8.3. 字符类型8.4. 二进制数据类型8.5. 日期/时间类型8.6. 布尔类型8.7. 枚举类型8.8. 几何类型8.9. 网络地址类型8.10. 位串类型8.11. 文本搜索类型8.12. UUID类型8.13. XML类型8.14. 数组8.15. 复合类型8.16. 对象标识符类型8.17. 伪类型章 9. 函数和操作符9.1. 逻辑操作符9.2. 比较操作符9.3. 数学函数和操作符9.4. 字符串函数和操作符9.5. 二进制字符串函数和操作符9.6. 位串函数和操作符9.7. 模式匹配9.8. 数据类型格式化函数9.9. 时间/日期函数和操作符9.10. 支持枚举函数9.11. 几何函数和操作符9.12. 网络地址函数和操作符9.13. 文本检索函数和操作符9.14. XML函数9.15. 序列操作函数9.16. 条件表达式9.17. 数组函数和操作符9.18. 聚合函数9.19. 窗口函数9.20. 子查询表达式9.21. 行和数组比较9.22. 返回集合的函数9.23. 系统信息函数9.24. 系统管理函数9.25. 触发器函数章10. 类型转换10.3. 函数10.2. 操作符10.1. 概述10.4. 值存储10.5. UNION章11. 索引11.1. 介绍11.2. 索引类型11.3. 多字段索引11.4. 索引和ORDER BY11.5. 组合多个索引11.6. 唯一索引11.7. 表达式上的索引11.8. 部分索引11.9. 操作类和操作簇11.10. 检查索引的使用章12. Full Text Search12.1. Introduction12.2. Tables and Indexes12.3. Controlling Text Search12.4. Additional Features12.5. Parsers12.6. Dictionaries12.7. Configuration Example12.8. Testing and Debugging Text Search12.9. GiST and GIN Index Types12.10. psql Support12.11. Limitations12.12. Migration from Pre-8.3 Text Search章13. 并发控制13.1. 介绍13.2. 事务隔离13.3. 明确锁定13.4. 应用层数据完整性检查13.5. 锁和索引章14. 性能提升技巧14.1. 使用EXPLAIN14.2. 规划器使用的统计信息14.3. 用明确的JOIN语句控制规划器14.4. 向数据库中添加记录14.5. 非持久性设置III. 服务器管理章15. 安装指导15.1. 简版15.2. 要求15.3. 获取源码15.4. 升级15.5. 安装过程15.6. 安装后的设置15.7. 支持的平台15.8. 特殊平台的要求章16. Installation from Source Code on Windows16.1. Building with Visual C++ or the Platform SDK16.2. Building libpq with Visual C++ or Borland C++章17. 服务器安装和操作17.1. PostgreSQL用户帐户17.2. 创建数据库集群17.3. 启动数据库服务器17.4. 管理内核资源17.5. 关闭服务17.6. 防止服务器欺骗17.7. 加密选项17.8. 用SSL进行安全的TCP/IP连接17.9. Secure TCP/IP Connections with SSH Tunnels章18. 服务器配置18.1. 设置参数18.2. 文件位置18.3. 连接和认证18.4. 资源消耗18.5. 预写式日志18.6. 查询规划18.7. 错误报告和日志18.8. 运行时统计18.9. 自动清理18.10. 客户端连接缺省18.12. 版本和平台兼容性18.11. 锁管理18.13. 预置选项18.14. 自定义的选项18.15. 开发人员选项18.16. 短选项章19. 用户认证19.1. pg_hba.conf 文件19.2. 用户名映射19.3. 认证方法19.4. 用户认证章20. 数据库角色和权限20.1. 数据库角色20.2. 角色属性20.3. 权限20.4. 角色成员20.5. 函数和触发器章21. 管理数据库21.1. 概述21.2. 创建一个数据库21.3. 临时库21.4. 数据库配置21.5. 删除数据库21.6. 表空间章22. 本土化22.1. 区域支持22.2. 字符集支持章23. 日常数据库维护工作23.1. Routine Vacuuming日常清理23.2. 经常重建索引23.3. 日志文件维护章24. 备份和恢复24.1. SQL转储24.2. 文件系统级别的备份24.3. 在线备份以及即时恢复(PITR)24.4. 版本间迁移章25. 高可用性与负载均衡,复制25.1. 不同解决方案的比较25.2. 日志传送备份服务器25.3. 失效切换25.4. 日志传送的替代方法25.5. 热备章26. 恢复配置26.1. 归档恢复设置26.2. 恢复目标设置26.3. 备服务器设置章27. 监控数据库的活动27.1. 标准Unix工具27.2. 统计收集器27.3. 查看锁27.4. 动态跟踪章28. 监控磁盘使用情况28.1. 判断磁盘的使用量28.2. 磁盘满导致的失效章29. 可靠性和预写式日志29.1. 可靠性29.2. 预写式日志(WAL)29.3. 异步提交29.4. WAL配置29.5. WAL内部章30. Regression Tests30.1. Running the Tests30.2. Test Evaluation30.3. Variant Comparison Files30.4. Test Coverage ExaminationIV. 客户端接口章31. libpq-C库31.1. 数据库联接函数31.2. 连接状态函数31.3. 命令执行函数31.4. 异步命令处理31.5. 取消正在处理的查询31.6. 捷径接口31.7. 异步通知31.8. 与COPY命令相关的函数31.9. Control Functions 控制函数31.10. 其他函数31.11. 注意信息处理31.12. 事件系统31.13. 环境变量31.14. 口令文件31.15. 连接服务的文件31.16. LDAP查找连接参数31.17. SSL支持31.18. 在多线程程序里的行为31.19. 制作libpq程序31.20. 例子程序章32. 大对象32.1. 介绍32.2. 实现特点32.3. 客户端接口32.4. 服务器端函数32.5. 例子程序章33. ECPG - Embedded SQL in C33.1. The Concept33.2. Connecting to the Database Server33.3. Closing a Connection33.4. Running SQL Commands33.5. Choosing a Connection33.6. Using Host Variables33.7. Dynamic SQL33.8. pgtypes library33.9. Using Descriptor Areas33.10. Informix compatibility mode33.11. Error Handling33.12. Preprocessor directives33.13. Processing Embedded SQL Programs33.14. Library Functions33.15. Internals章34. 信息模式34.1. 关于这个模式34.2. 数据类型34.3. information_schema_catalog_name34.4. administrable_role_authorizations34.5. applicable_roles34.6. attributes34.7. check_constraint_routine_usage34.8. check_constraints34.9. column_domain_usage34.10. column_privileges34.11. column_udt_usage34.12. 字段34.13. constraint_column_usage34.14. constraint_table_usage34.15. data_type_privileges34.16. domain_constraints34.18. domains34.17. domain_udt_usage34.19. element_types34.20. enabled_roles34.21. foreign_data_wrapper_options34.22. foreign_data_wrappers34.23. foreign_server_options34.24. foreign_servers34.25. key_column_usage34.26. parameters34.27. referential_constraints34.28. role_column_grants34.29. role_routine_grants34.30. role_table_grants34.31. role_usage_grants34.32. routine_privileges34.33. routines34.34. schemata34.35. sequences34.36. sql_features34.37. sql_implementation_info34.38. sql_languages34.39. sql_packages34.40. sql_parts34.41. sql_sizing34.42. sql_sizing_profiles34.43. table_constraints34.44. table_privileges34.45. tables34.46. triggered_update_columns34.47. 触发器34.48. usage_privileges34.49. user_mapping_options34.50. user_mappings34.51. view_column_usage34.52. view_routine_usage34.53. view_table_usage34.54. 视图V. 服务器端编程章35. 扩展SQL35.1. 扩展性是如何实现的35.2. PostgreSQL类型系统35.3. User-Defined Functions35.4. Query Language (SQL) Functions35.5. Function Overloading35.6. Function Volatility Categories35.7. Procedural Language Functions35.8. Internal Functions35.9. C-Language Functions35.10. User-Defined Aggregates35.11. User-Defined Types35.12. User-Defined Operators35.13. Operator Optimization Information35.14. Interfacing Extensions To Indexes35.15. 用C++扩展章36. 触发器36.1. 触发器行为概述36.3. 用 C 写触发器36.2. 数据改变的可视性36.4. 一个完整的例子章37. 规则系统37.1. The Query Tree37.2. 视图和规则系统37.3. 在INSERT,UPDATE和DELETE上的规则37.4. 规则和权限37.5. 规则和命令状态37.6. 规则与触发器得比较章38. Procedural Languages38.1. Installing Procedural Languages章39. PL/pgSQL - SQL过程语言39.1. 概述39.2. PL/pgSQL的结构39.3. 声明39.4. 表达式39.5. 基本语句39.6. 控制结构39.7. 游标39.8. 错误和消息39.9. 触发器过程39.10. PL/pgSQL Under the Hood39.11. 开发PL/pgSQL的一些提示39.12. 从OraclePL/SQL 进行移植章40. PL/Tcl - Tcl Procedural Language40.1. Overview40.2. PL/Tcl Functions and Arguments40.3. Data Values in PL/Tcl40.4. Global Data in PL/Tcl40.5. Database Access from PL/Tcl40.6. Trigger Procedures in PL/Tcl40.7. Modules and the unknown command40.8. Tcl Procedure Names章41. PL/Perl - Perl Procedural Language41.1. PL/Perl Functions and Arguments41.2. Data Values in PL/Perl41.3. Built-in Functions41.4. Global Values in PL/Perl41.6. PL/Perl Triggers41.5. Trusted and Untrusted PL/Perl41.7. PL/Perl Under the Hood章42. PL/Python - Python Procedural Language42.1. Python 2 vs. Python 342.2. PL/Python Functions42.3. Data Values42.4. Sharing Data42.5. Anonymous Code Blocks42.6. Trigger Functions42.7. Database Access42.8. Utility Functions42.9. Environment Variables章43. Server Programming Interface43.1. Interface FunctionsSpi-spi-connectSpi-spi-finishSpi-spi-pushSpi-spi-popSpi-spi-executeSpi-spi-execSpi-spi-execute-with-argsSpi-spi-prepareSpi-spi-prepare-cursorSpi-spi-prepare-paramsSpi-spi-getargcountSpi-spi-getargtypeidSpi-spi-is-cursor-planSpi-spi-execute-planSpi-spi-execute-plan-with-paramlistSpi-spi-execpSpi-spi-cursor-openSpi-spi-cursor-open-with-argsSpi-spi-cursor-open-with-paramlistSpi-spi-cursor-findSpi-spi-cursor-fetchSpi-spi-cursor-moveSpi-spi-scroll-cursor-fetchSpi-spi-scroll-cursor-moveSpi-spi-cursor-closeSpi-spi-saveplan43.2. Interface Support FunctionsSpi-spi-fnameSpi-spi-fnumberSpi-spi-getvalueSpi-spi-getbinvalSpi-spi-gettypeSpi-spi-gettypeidSpi-spi-getrelnameSpi-spi-getnspname43.3. Memory ManagementSpi-spi-pallocSpi-reallocSpi-spi-pfreeSpi-spi-copytupleSpi-spi-returntupleSpi-spi-modifytupleSpi-spi-freetupleSpi-spi-freetupletableSpi-spi-freeplan43.4. Visibility of Data Changes43.5. ExamplesVI. 参考手册I. SQL命令Sql-abortSql-alteraggregateSql-alterconversionSql-alterdatabaseSql-alterdefaultprivilegesSql-alterdomainSql-alterforeigndatawrapperSql-alterfunctionSql-altergroupSql-alterindexSql-alterlanguageSql-alterlargeobjectSql-alteroperatorSql-alteropclassSql-alteropfamilySql-alterroleSql-alterschemaSql-altersequenceSql-alterserverSql-altertableSql-altertablespaceSql-altertsconfigSql-altertsdictionarySql-altertsparserSql-altertstemplateSql-altertriggerSql-altertypeSql-alteruserSql-alterusermappingSql-alterviewSql-analyzeSql-beginSql-checkpointSql-closeSql-clusterSql-commentSql-commitSql-commit-preparedSql-copySql-createaggregateSql-createcastSql-createconstraintSql-createconversionSql-createdatabaseSql-createdomainSql-createforeigndatawrapperSql-createfunctionSql-creategroupSql-createindexSql-createlanguageSql-createoperatorSql-createopclassSql-createopfamilySql-createroleSql-createruleSql-createschemaSql-createsequenceSql-createserverSql-createtableSql-createtableasSql-createtablespaceSql-createtsconfigSql-createtsdictionarySql-createtsparserSql-createtstemplateSql-createtriggerSql-createtypeSql-createuserSql-createusermappingSql-createviewSql-deallocateSql-declareSql-deleteSql-discardSql-doSql-dropaggregateSql-dropcastSql-dropconversionSql-dropdatabaseSql-dropdomainSql-dropforeigndatawrapperSql-dropfunctionSql-dropgroupSql-dropindexSql-droplanguageSql-dropoperatorSql-dropopclassSql-dropopfamilySql-drop-ownedSql-droproleSql-dropruleSql-dropschemaSql-dropsequenceSql-dropserverSql-droptableSql-droptablespaceSql-droptsconfigSql-droptsdictionarySql-droptsparserSql-droptstemplateSql-droptriggerSql-droptypeSql-dropuserSql-dropusermappingSql-dropviewSql-endSql-executeSql-explainSql-fetchSql-grantSql-insertSql-listenSql-loadSql-lockSql-moveSql-notifySql-prepareSql-prepare-transactionSql-reassign-ownedSql-reindexSql-release-savepointSql-resetSql-revokeSql-rollbackSql-rollback-preparedSql-rollback-toSql-savepointSql-selectSql-selectintoSql-setSql-set-constraintsSql-set-roleSql-set-session-authorizationSql-set-transactionSql-showSql-start-transactionSql-truncateSql-unlistenSql-updateSql-vacuumSql-valuesII. 客户端应用程序App-clusterdbApp-createdbApp-createlangApp-createuserApp-dropdbApp-droplangApp-dropuserApp-ecpgApp-pgconfigApp-pgdumpApp-pg-dumpallApp-pgrestoreApp-psqlApp-reindexdbApp-vacuumdbIII. PostgreSQL服务器应用程序App-initdbApp-pgcontroldataApp-pg-ctlApp-pgresetxlogApp-postgresApp-postmasterVII. 内部章44. PostgreSQL内部概览44.1. 查询路径44.2. 连接是如何建立起来的44.3. 分析器阶段44.4. ThePostgreSQL规则系统44.5. 规划器/优化器44.6. 执行器章45. 系统表45.1. 概述45.2. pg_aggregate45.3. pg_am45.4. pg_amop45.5. pg_amproc45.6. pg_attrdef45.7. pg_attribute45.8. pg_authid45.9. pg_auth_members45.10. pg_cast45.11. pg_class45.12. pg_constraint45.13. pg_conversion45.14. pg_database45.15. pg_db_role_setting45.16. pg_default_acl45.17. pg_depend45.18. pg_description45.19. pg_enum45.20. pg_foreign_data_wrapper45.21. pg_foreign_server45.22. pg_index45.23. pg_inherits45.24. pg_language45.25. pg_largeobject45.26. pg_largeobject_metadata45.27. pg_namespace45.28. pg_opclass45.29. pg_operator45.30. pg_opfamily45.31. pg_pltemplate45.32. pg_proc45.33. pg_rewrite45.34. pg_shdepend45.35. pg_shdescription45.36. pg_statistic45.37. pg_tablespace45.38. pg_trigger45.39. pg_ts_config45.40. pg_ts_config_map45.41. pg_ts_dict45.42. pg_ts_parser45.43. pg_ts_template45.44. pg_type45.45. pg_user_mapping45.46. System Views45.47. pg_cursors45.48. pg_group45.49. pg_indexes45.50. pg_locks45.51. pg_prepared_statements45.52. pg_prepared_xacts45.53. pg_roles45.54. pg_rules45.55. pg_settings45.56. pg_shadow45.57. pg_stats45.58. pg_tables45.59. pg_timezone_abbrevs45.60. pg_timezone_names45.61. pg_user45.62. pg_user_mappings45.63. pg_views章46. Frontend/Backend Protocol46.1. Overview46.2. Message Flow46.3. Streaming Replication Protocol46.4. Message Data Types46.5. Message Formats46.6. Error and Notice Message Fields46.7. Summary of Changes since Protocol 2.047. PostgreSQL Coding Conventions47.1. Formatting47.2. Reporting Errors Within the Server47.3. Error Message Style Guide章48. Native Language Support48.1. For the Translator48.2. For the Programmer章49. Writing A Procedural Language Handler章50. Genetic Query Optimizer50.1. Query Handling as a Complex Optimization Problem50.2. Genetic Algorithms50.3. Genetic Query Optimization (GEQO) in PostgreSQL50.4. Further Reading章51. 索引访问方法接口定义51.1. 索引的系统表记录51.2. 索引访问方法函数51.3. 索引扫描51.4. 索引锁的考量51.5. 索引唯一性检查51.6. 索引开销估计函数章52. GiST Indexes52.1. Introduction52.2. Extensibility52.3. Implementation52.4. Examples52.5. Crash Recovery章53. GIN Indexes53.1. Introduction53.2. Extensibility53.3. Implementation53.4. GIN tips and tricks53.5. Limitations53.6. Examples章54. 数据库物理存储54.1. 数据库文件布局54.2. TOAST54.3. 自由空间映射54.4. 可见映射54.5. 数据库分页文件章55. BKI后端接口55.1. BKI 文件格式55.2. BKI命令55.3. 系统初始化的BKI文件的结构55.4. 例子章56. 规划器如何使用统计信息56.1. 行预期的例子VIII. 附录A. PostgreSQL错误代码B. 日期/时间支持B.1. 日期/时间输入解析B.2. 日期/时间关键字B.3. 日期/时间配置文件B.4. 日期单位的历史C. SQL关键字D. SQL ConformanceD.1. Supported FeaturesD.2. Unsupported FeaturesE. Release NotesRelease-0-01Release-0-02Release-0-03Release-1-0Release-1-01Release-1-02Release-1-09Release-6-0Release-6-1Release-6-1-1Release-6-2Release-6-2-1Release-6-3Release-6-3-1Release-6-3-2Release-6-4Release-6-4-1Release-6-4-2Release-6-5Release-6-5-1Release-6-5-2Release-6-5-3Release-7-0Release-7-0-1Release-7-0-2Release-7-0-3Release-7-1Release-7-1-1Release-7-1-2Release-7-1-3Release-7-2Release-7-2-1Release-7-2-2Release-7-2-3Release-7-2-4Release-7-2-5Release-7-2-6Release-7-2-7Release-7-2-8Release-7-3Release-7-3-1Release-7-3-10Release-7-3-11Release-7-3-12Release-7-3-13Release-7-3-14Release-7-3-15Release-7-3-16Release-7-3-17Release-7-3-18Release-7-3-19Release-7-3-2Release-7-3-20Release-7-3-21Release-7-3-3Release-7-3-4Release-7-3-5Release-7-3-6Release-7-3-7Release-7-3-8Release-7-3-9Release-7-4Release-7-4-1Release-7-4-10Release-7-4-11Release-7-4-12Release-7-4-13Release-7-4-14Release-7-4-15Release-7-4-16Release-7-4-17Release-7-4-18Release-7-4-19Release-7-4-2Release-7-4-20Release-7-4-21Release-7-4-22Release-7-4-23Release-7-4-24Release-7-4-25Release-7-4-26Release-7-4-27Release-7-4-28Release-7-4-29Release-7-4-3Release-7-4-30Release-7-4-4Release-7-4-5Release-7-4-6Release-7-4-7Release-7-4-8Release-7-4-9Release-8-0Release-8-0-1Release-8-0-10Release-8-0-11Release-8-0-12Release-8-0-13Release-8-0-14Release-8-0-15Release-8-0-16Release-8-0-17Release-8-0-18Release-8-0-19Release-8-0-2Release-8-0-20Release-8-0-21Release-8-0-22Release-8-0-23Release-8-0-24Release-8-0-25Release-8-0-26Release-8-0-3Release-8-0-4Release-8-0-5Release-8-0-6Release-8-0-7Release-8-0-8Release-8-0-9Release-8-1Release-8-1-1Release-8-1-10Release-8-1-11Release-8-1-12Release-8-1-13Release-8-1-14Release-8-1-15Release-8-1-16Release-8-1-17Release-8-1-18Release-8-1-19Release-8-1-2Release-8-1-20Release-8-1-21Release-8-1-22Release-8-1-23Release-8-1-3Release-8-1-4Release-8-1-5Release-8-1-6Release-8-1-7Release-8-1-8Release-8-1-9Release-8-2Release-8-2-1Release-8-2-10Release-8-2-11Release-8-2-12Release-8-2-13Release-8-2-14Release-8-2-15Release-8-2-16Release-8-2-17Release-8-2-18Release-8-2-19Release-8-2-2Release-8-2-20Release-8-2-21Release-8-2-3Release-8-2-4Release-8-2-5Release-8-2-6Release-8-2-7Release-8-2-8Release-8-2-9Release-8-3Release-8-3-1Release-8-3-10Release-8-3-11Release-8-3-12Release-8-3-13Release-8-3-14Release-8-3-15Release-8-3-2Release-8-3-3Release-8-3-4Release-8-3-5Release-8-3-6Release-8-3-7Release-8-3-8Release-8-3-9Release-8-4Release-8-4-1Release-8-4-2Release-8-4-3Release-8-4-4Release-8-4-5Release-8-4-6Release-8-4-7Release-8-4-8Release-9-0Release-9-0-1Release-9-0-2Release-9-0-3Release-9-0-4F. 额外提供的模块F.1. adminpackF.2. auto_explainF.3. btree_ginF.4. btree_gistF.5. chkpassF.6. citextF.7. cubeF.8. dblinkContrib-dblink-connectContrib-dblink-connect-uContrib-dblink-disconnectContrib-dblinkContrib-dblink-execContrib-dblink-openContrib-dblink-fetchContrib-dblink-closeContrib-dblink-get-connectionsContrib-dblink-error-messageContrib-dblink-send-queryContrib-dblink-is-busyContrib-dblink-get-notifyContrib-dblink-get-resultContrib-dblink-cancel-queryContrib-dblink-get-pkeyContrib-dblink-build-sql-insertContrib-dblink-build-sql-deleteContrib-dblink-build-sql-updateF.9. dict_intF.10. dict_xsynF.11. earthdistanceF.12. fuzzystrmatchF.13. hstoreF.14. intaggF.15. intarrayF.16. isnF.17. loF.18. ltreeF.19. oid2nameF.20. pageinspectF.21. passwordcheckF.22. pg_archivecleanupF.23. pgbenchF.24. pg_buffercacheF.25. pgcryptoF.26. pg_freespacemapF.27. pgrowlocksF.28. pg_standbyF.29. pg_stat_statementsF.30. pgstattupleF.31. pg_trgmF.32. pg_upgradeF.33. segF.34. spiF.35. sslinfoF.36. tablefuncF.37. test_parserF.38. tsearch2F.39. unaccentF.40. uuid-osspF.41. vacuumloF.42. xml2G. 外部项目G.1. 客户端接口G.2. 过程语言G.3. 扩展H. The Source Code RepositoryH.1. Getting The Source Via GitI. 文档I.1. DocBookI.2. 工具集I.3. 制作文档I.4. 文档写作I.5. 风格指导J. 首字母缩略词参考书目BookindexIndex
文字

12.6. Dictionaries

Dictionaries are used to eliminate words that should not be considered in a search (stop words), and to normalize words so that different derived forms of the same word will match. A successfully normalized word is called a lexeme. Aside from improving search quality, normalization and removal of stop words reduce the size of the tsvector representation of a document, thereby improving performance. Normalization does not always have linguistic meaning and usually depends on application semantics.

Some examples of normalization:

  • Linguistic - Ispell dictionaries try to reduce input words to a normalized form; stemmer dictionaries remove word endings

  • URL locations can be canonicalized to make equivalent URLs match:

    • http://www.pgsql.ru/db/mw/index.html

    • http://www.pgsql.ru/db/mw/

    • http://www.pgsql.ru/db/../db/mw/index.html

  • Color names can be replaced by their hexadecimal values, e.g., red, green, blue, magenta -> FF0000, 00FF00, 0000FF, FF00FF

  • If indexing numbers, we can remove some fractional digits to reduce the range of possible numbers, so for example 3.14159265359, 3.1415926, 3.14 will be the same after normalization if only two digits are kept after the decimal point.

A dictionary is a program that accepts a token as input and returns:

  • an array of lexemes if the input token is known to the dictionary (notice that one token can produce more than one lexeme)

  • a single lexeme with the TSL_FILTER flag set, to replace the original token with a new token to be passed to subsequent dictionaries (a dictionary that does this is called a filtering dictionary)

  • an empty array if the dictionary knows the token, but it is a stop word

  • NULL if the dictionary does not recognize the input token

PostgreSQL provides predefined dictionaries for many languages. There are also several predefined templates that can be used to create new dictionaries with custom parameters. Each predefined dictionary template is described below. If no existing template is suitable, it is possible to create new ones; see the contrib/ area of the PostgreSQL distribution for examples.

A text search configuration binds a parser together with a set of dictionaries to process the parser's output tokens. For each token type that the parser can return, a separate list of dictionaries is specified by the configuration. When a token of that type is found by the parser, each dictionary in the list is consulted in turn, until some dictionary recognizes it as a known word. If it is identified as a stop word, or if no dictionary recognizes the token, it will be discarded and not indexed or searched for. Normally, the first dictionary that returns a non-NULL output determines the result, and any remaining dictionaries are not consulted; but a filtering dictionary can replace the given word with a modified word, which is then passed to subsequent dictionaries.

The general rule for configuring a list of dictionaries is to place first the most narrow, most specific dictionary, then the more general dictionaries, finishing with a very general dictionary, like a Snowball stemmer or simple, which recognizes everything. For example, for an astronomy-specific search (astro_en configuration) one could bind token type asciiword (ASCII word) to a synonym dictionary of astronomical terms, a general English dictionary and a Snowball English stemmer:

ALTER TEXT SEARCH CONFIGURATION astro_en
    ADD MAPPING FOR asciiword WITH astrosyn, english_ispell, english_stem;

A filtering dictionary can be placed anywhere in the list, except at the end where it'd be useless. Filtering dictionaries are useful to partially normalize words to simplify the task of later dictionaries. For example, a filtering dictionary could be used to remove accents from accented letters, as is done by the contrib/unaccent extension module.

12.6.1. Stop Words

Stop words are words that are very common, appear in almost every document, and have no discrimination value. Therefore, they can be ignored in the context of full text searching. For example, every English text contains words like a and the, so it is useless to store them in an index. However, stop words do affect the positions in tsvector, which in turn affect ranking:

SELECT to_tsvector('english','in the list of stop words');
        to_tsvector
----------------------------
 'list':3 'stop':5 'word':6

The missing positions 1,2,4 are because of stop words. Ranks calculated for documents with and without stop words are quite different:

SELECT ts_rank_cd (to_tsvector('english','in the list of stop words'), to_tsquery('list & stop'));
 ts_rank_cd
------------
       0.05

SELECT ts_rank_cd (to_tsvector('english','list stop words'), to_tsquery('list & stop'));
 ts_rank_cd
------------
        0.1

It is up to the specific dictionary how it treats stop words. For example, ispell dictionaries first normalize words and then look at the list of stop words, while Snowball stemmers first check the list of stop words. The reason for the different behavior is an attempt to decrease noise.

12.6.2. Simple Dictionary

The simple dictionary template operates by converting the input token to lower case and checking it against a file of stop words. If it is found in the file then an empty array is returned, causing the token to be discarded. If not, the lower-cased form of the word is returned as the normalized lexeme. Alternatively, the dictionary can be configured to report non-stop-words as unrecognized, allowing them to be passed on to the next dictionary in the list.

Here is an example of a dictionary definition using the simple template:

CREATE TEXT SEARCH DICTIONARY public.simple_dict (
    TEMPLATE = pg_catalog.simple,
    STOPWORDS = english
);

Here, english is the base name of a file of stop words. The file's full name will be $SHAREDIR/tsearch_data/english.stop, where $SHAREDIR means the PostgreSQL installation's shared-data directory, often /usr/local/share/postgresql (use pg_config --sharedir to determine it if you're not sure). The file format is simply a list of words, one per line. Blank lines and trailing spaces are ignored, and upper case is folded to lower case, but no other processing is done on the file contents.

Now we can test our dictionary:

SELECT ts_lexize('public.simple_dict','YeS');
 ts_lexize
-----------
 {yes}

SELECT ts_lexize('public.simple_dict','The');
 ts_lexize
-----------
 {}

We can also choose to return NULL, instead of the lower-cased word, if it is not found in the stop words file. This behavior is selected by setting the dictionary's Accept parameter to false. Continuing the example:

ALTER TEXT SEARCH DICTIONARY public.simple_dict ( Accept = false );

SELECT ts_lexize('public.simple_dict','YeS');
 ts_lexize
-----------


SELECT ts_lexize('public.simple_dict','The');
 ts_lexize
-----------
 {}

With the default setting of Accept = true, it is only useful to place a simple dictionary at the end of a list of dictionaries, since it will never pass on any token to a following dictionary. Conversely, Accept = false is only useful when there is at least one following dictionary.

Caution

Most types of dictionaries rely on configuration files, such as files of stop words. These files must be stored in UTF-8 encoding. They will be translated to the actual database encoding, if that is different, when they are read into the server.

Caution

Normally, a database session will read a dictionary configuration file only once, when it is first used within the session. If you modify a configuration file and want to force existing sessions to pick up the new contents, issue an ALTER TEXT SEARCH DICTIONARY command on the dictionary. This can be a "dummy" update that doesn't actually change any parameter values.

12.6.3. Synonym Dictionary

This dictionary template is used to create dictionaries that replace a word with a synonym. Phrases are not supported (use the thesaurus template (Section 12.6.4) for that). A synonym dictionary can be used to overcome linguistic problems, for example, to prevent an English stemmer dictionary from reducing the word 'Paris' to 'pari'. It is enough to have a Paris paris line in the synonym dictionary and put it before the english_stem dictionary. For example:

SELECT * FROM ts_debug('english', 'Paris');
   alias   |   description   | token |  dictionaries  |  dictionary  | lexemes 
-----------+-----------------+-------+----------------+--------------+---------
 asciiword | Word, all ASCII | Paris | {english_stem} | english_stem | {pari}

CREATE TEXT SEARCH DICTIONARY my_synonym (
    TEMPLATE = synonym,
    SYNONYMS = my_synonyms
);

ALTER TEXT SEARCH CONFIGURATION english
    ALTER MAPPING FOR asciiword
    WITH my_synonym, english_stem;

SELECT * FROM ts_debug('english', 'Paris');
   alias   |   description   | token |       dictionaries        | dictionary | lexemes 
-----------+-----------------+-------+---------------------------+------------+---------
 asciiword | Word, all ASCII | Paris | {my_synonym,english_stem} | my_synonym | {paris}

The only parameter required by the synonym template is SYNONYMS, which is the base name of its configuration file — my_synonyms in the above example. The file's full name will be $SHAREDIR/tsearch_data/my_synonyms.syn (where $SHAREDIR means the PostgreSQL installation's shared-data directory). The file format is just one line per word to be substituted, with the word followed by its synonym, separated by white space. Blank lines and trailing spaces are ignored.

The synonym template also has an optional parameter CaseSensitive, which defaults to false. When CaseSensitive is false, words in the synonym file are folded to lower case, as are input tokens. When it is true, words and tokens are not folded to lower case, but are compared as-is.

An asterisk (*) can be placed at the end of a synonym in the configuration file. This indicates that the synonym is a prefix. The asterisk is ignored when the entry is used in to_tsvector(), but when it is used in to_tsquery(), the result will be a query item with the prefix match marker (see Section 12.3.2). For example, suppose we have these entries in $SHAREDIR/tsearch_data/synonym_sample.syn:

postgres        pgsql
postgresql      pgsql
postgre pgsql
gogle   googl
indices index*

Then we will get these results:

mydb=# CREATE TEXT SEARCH DICTIONARY syn (template=synonym, synonyms='synonym_sample');
mydb=# SELECT ts_lexize('syn','indices');
 ts_lexize
-----------
 {index}
(1 row)

mydb=# CREATE TEXT SEARCH CONFIGURATION tst (copy=simple);
mydb=# ALTER TEXT SEARCH CONFIGURATION tst ALTER MAPPING FOR asciiword WITH syn;
mydb=# SELECT to_tsvector('tst','indices');
 to_tsvector
-------------
 'index':1
(1 row)

mydb=# SELECT to_tsquery('tst','indices');
 to_tsquery
------------
 'index':*
(1 row)

mydb=# SELECT 'indexes are very useful'::tsvector;
            tsvector             
---------------------------------
 'are' 'indexes' 'useful' 'very'
(1 row)

mydb=# SELECT 'indexes are very useful'::tsvector @@ to_tsquery('tst','indices');
 ?column?
----------
 t
(1 row)

12.6.4. Thesaurus Dictionary

A thesaurus dictionary (sometimes abbreviated as TZ) is a collection of words that includes information about the relationships of words and phrases, i.e., broader terms (BT), narrower terms (NT), preferred terms, non-preferred terms, related terms, etc.

Basically a thesaurus dictionary replaces all non-preferred terms by one preferred term and, optionally, preserves the original terms for indexing as well. PostgreSQL's current implementation of the thesaurus dictionary is an extension of the synonym dictionary with added phrase support. A thesaurus dictionary requires a configuration file of the following format:

# this is a comment
sample word(s) : indexed word(s)
more sample word(s) : more indexed word(s)
...

where the colon (:) symbol acts as a delimiter between a a phrase and its replacement.

A thesaurus dictionary uses a subdictionary (which is specified in the dictionary's configuration) to normalize the input text before checking for phrase matches. It is only possible to select one subdictionary. An error is reported if the subdictionary fails to recognize a word. In that case, you should remove the use of the word or teach the subdictionary about it. You can place an asterisk (*) at the beginning of an indexed word to skip applying the subdictionary to it, but all sample words must be known to the subdictionary.

The thesaurus dictionary chooses the longest match if there are multiple phrases matching the input, and ties are broken by using the last definition.

Specific stop words recognized by the subdictionary cannot be specified; instead use ? to mark the location where any stop word can appear. For example, assuming that a and the are stop words according to the subdictionary:

? one ? two : swsw

matches a one the two and the one a two; both would be replaced by swsw.

Since a thesaurus dictionary has the capability to recognize phrases it must remember its state and interact with the parser. A thesaurus dictionary uses these assignments to check if it should handle the next word or stop accumulation. The thesaurus dictionary must be configured carefully. For example, if the thesaurus dictionary is assigned to handle only the asciiword token, then a thesaurus dictionary definition like one 7 will not work since token type uint is not assigned to the thesaurus dictionary.

Caution

Thesauruses are used during indexing so any change in the thesaurus dictionary's parameters requires reindexing. For most other dictionary types, small changes such as adding or removing stopwords does not force reindexing.

12.6.4.1. Thesaurus Configuration

To define a new thesaurus dictionary, use the thesaurus template. For example:

CREATE TEXT SEARCH DICTIONARY thesaurus_simple (
    TEMPLATE = thesaurus,
    DictFile = mythesaurus,
    Dictionary = pg_catalog.english_stem
);

Here:

  • thesaurus_simple is the new dictionary's name

  • mythesaurus is the base name of the thesaurus configuration file. (Its full name will be $SHAREDIR/tsearch_data/mythesaurus.ths, where $SHAREDIR means the installation shared-data directory.)

  • pg_catalog.english_stem is the subdictionary (here, a Snowball English stemmer) to use for thesaurus normalization. Notice that the subdictionary will have its own configuration (for example, stop words), which is not shown here.

Now it is possible to bind the thesaurus dictionary thesaurus_simple to the desired token types in a configuration, for example:

ALTER TEXT SEARCH CONFIGURATION russian
    ALTER MAPPING FOR asciiword, asciihword, hword_asciipart
    WITH thesaurus_simple;

12.6.4.2. Thesaurus Example

Consider a simple astronomical thesaurus thesaurus_astro, which contains some astronomical word combinations:

supernovae stars : sn
crab nebulae : crab

Below we create a dictionary and bind some token types to an astronomical thesaurus and English stemmer:

CREATE TEXT SEARCH DICTIONARY thesaurus_astro (
    TEMPLATE = thesaurus,
    DictFile = thesaurus_astro,
    Dictionary = english_stem
);

ALTER TEXT SEARCH CONFIGURATION russian
    ALTER MAPPING FOR asciiword, asciihword, hword_asciipart
    WITH thesaurus_astro, english_stem;

Now we can see how it works. ts_lexize is not very useful for testing a thesaurus, because it treats its input as a single token. Instead we can use plainto_tsquery and to_tsvector which will break their input strings into multiple tokens:

SELECT plainto_tsquery('supernova star');
 plainto_tsquery
-----------------
 'sn'

SELECT to_tsvector('supernova star');
 to_tsvector
-------------
 'sn':1

In principle, one can use to_tsquery if you quote the argument:

SELECT to_tsquery('''supernova star''');
 to_tsquery
------------
 'sn'

Notice that supernova star matches supernovae stars in thesaurus_astro because we specified the english_stem stemmer in the thesaurus definition. The stemmer removed the e and s.

To index the original phrase as well as the substitute, just include it in the right-hand part of the definition:

supernovae stars : sn supernovae stars

SELECT plainto_tsquery('supernova star');
       plainto_tsquery
-----------------------------
 'sn' & 'supernova' & 'star'

12.6.5. Ispell Dictionary

The Ispell dictionary template supports morphological dictionaries, which can normalize many different linguistic forms of a word into the same lexeme. For example, an English Ispell dictionary can match all declensions and conjugations of the search term bank, e.g., banking, banked, banks, banks', and bank's.

The standard PostgreSQL distribution does not include any Ispell configuration files. Dictionaries for a large number of languages are available from Ispell. Also, some more modern dictionary file formats are supported — MySpell (OO < 2.0.1) and Hunspell (OO >= 2.0.2). A large list of dictionaries is available on the OpenOffice Wiki.

To create an Ispell dictionary, use the built-in ispell template and specify several parameters:

CREATE TEXT SEARCH DICTIONARY english_ispell (
    TEMPLATE = ispell,
    DictFile = english,
    AffFile = english,
    StopWords = english
);

Here, DictFile, AffFile, and StopWords specify the base names of the dictionary, affixes, and stop-words files. The stop-words file has the same format explained above for the simple dictionary type. The format of the other files is not specified here but is available from the above-mentioned web sites.

Ispell dictionaries usually recognize a limited set of words, so they should be followed by another broader dictionary; for example, a Snowball dictionary, which recognizes everything.

Ispell dictionaries support splitting compound words; a useful feature. Notice that the affix file should specify a special flag using the compoundwords controlled statement that marks dictionary words that can participate in compound formation:

compoundwords  controlled z

Here are some examples for the Norwegian language:

SELECT ts_lexize('norwegian_ispell', 'overbuljongterningpakkmesterassistent');
   {over,buljong,terning,pakk,mester,assistent}
SELECT ts_lexize('norwegian_ispell', 'sjokoladefabrikk');
   {sjokoladefabrikk,sjokolade,fabrikk}

Note: MySpell does not support compound words. Hunspell has sophisticated support for compound words. At present, PostgreSQL implements only the basic compound word operations of Hunspell.

12.6.6. Snowball Dictionary

The Snowball dictionary template is based on a project by Martin Porter, inventor of the popular Porter's stemming algorithm for the English language. Snowball now provides stemming algorithms for many languages (see the Snowball site for more information). Each algorithm understands how to reduce common variant forms of words to a base, or stem, spelling within its language. A Snowball dictionary requires a language parameter to identify which stemmer to use, and optionally can specify a stopword file name that gives a list of words to eliminate. (PostgreSQL's standard stopword lists are also provided by the Snowball project.) For example, there is a built-in definition equivalent to

CREATE TEXT SEARCH DICTIONARY english_stem (
    TEMPLATE = snowball,
    Language = english,
    StopWords = english
);

The stopword file format is the same as already explained.

A Snowball dictionary recognizes everything, whether or not it is able to simplify the word, so it should be placed at the end of the dictionary list. It is useless to have it before any other dictionary because a token will never pass through it to the next dictionary.

上一篇:下一篇: