Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
91e18dbb
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
91e18dbb
编写于
2月 06, 2007
作者:
T
Tom Lane
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Docs updates for cross-type hashing.
上级
8076c8c7
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
41 addition
and
15 deletion
+41
-15
doc/src/sgml/xindex.sgml
doc/src/sgml/xindex.sgml
+16
-7
doc/src/sgml/xoper.sgml
doc/src/sgml/xoper.sgml
+25
-8
未找到文件。
doc/src/sgml/xindex.sgml
浏览文件 @
91e18dbb
<!-- $PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.5
8 2007/02/01 00:28:18 momjian
Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/xindex.sgml,v 1.5
9 2007/02/06 04:38:31 tgl
Exp $ -->
<sect1 id="xindex">
<title>Interfacing Extensions To Indexes</title>
...
...
@@ -139,7 +139,7 @@
</table>
<para>
Hash indexes
express only bitwise equality
, and so they use only one
Hash indexes
support only equality comparisons
, and so they use only one
strategy, shown in <xref linkend="xindex-hash-strat-table">.
</para>
...
...
@@ -162,7 +162,7 @@
</table>
<para>
GiST indexes are
even
more flexible: they do not have a fixed set of
GiST indexes are more flexible: they do not have a fixed set of
strategies at all. Instead, the <quote>consistency</> support routine
of each particular GiST operator class interprets the strategy numbers
however it likes. As an example, several of the built-in GiST index
...
...
@@ -802,14 +802,23 @@ ALTER OPERATOR FAMILY integer_ops USING btree ADD
operator in the family there must be a support function having the same
two input data types as the operator. It is recommended that a family be
complete, i.e., for each combination of data types, all operators are
included.
An
operator class should include just the non-cross-type
included.
Each
operator class should include just the non-cross-type
operators and support function for its data type.
</para>
<para>
At this writing, hash indexes do not support cross-type operations,
and so there is little use for a hash operator family larger than one
operator class. This is expected to be relaxed in the future.
To build a multiple-data-type hash operator family, compatible hash
support functions must be created for each data type supported by the
family. Here compatibility means that the functions are guaranteed to
return the same hash code for any two values that are considered equal
by the family's equality operators, even when the values are of different
types. This is usually difficult to accomplish when the types have
different physical representations, but it can be done in some cases.
Notice that there is only one support function per data type, not one
per equality operator. It is recommended that a family be complete, i.e.,
provide an equality operator for each combination of data types.
Each operator class should include just the non-cross-type equality
operator and the support function for its data type.
</para>
<para>
...
...
doc/src/sgml/xoper.sgml
浏览文件 @
91e18dbb
<!-- $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.4
1 2007/02/01 19:10:24 momjian
Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.4
2 2007/02/06 04:38:31 tgl
Exp $ -->
<sect1 id="xoper">
<title>User-Defined Operators</title>
...
...
@@ -85,7 +85,7 @@ SELECT (a + b) AS c FROM test_complex;
appropriate, because they can make for considerable speedups in execution
of queries that use the operator. But if you provide them, you must be
sure that they are right! Incorrect use of an optimization clause can
result in s
erver process crash
es, subtly wrong output, or other Bad Things.
result in s
low queri
es, subtly wrong output, or other Bad Things.
You can always leave out an optimization clause if you are not sure
about it; the only consequence is that queries might run slower than
they need to.
...
...
@@ -326,8 +326,8 @@ table1.column1 OP table2.column2
The <literal>HASHES</literal> clause, if present, tells the system that
it is permissible to use the hash join method for a join based on this
operator. <literal>HASHES</> only makes sense for a binary operator that
returns <literal>boolean</>, and in practice the operator
had better be
equality for some data type.
returns <literal>boolean</>, and in practice the operator
must represent
equality for some data type
or pair of data types
.
</para>
<para>
...
...
@@ -337,7 +337,13 @@ table1.column1 OP table2.column2
join will never compare them at all, implicitly assuming that the
result of the join operator must be false. So it never makes sense
to specify <literal>HASHES</literal> for operators that do not represent
some form of equality.
some form of equality. In most cases it is only practical to support
hashing for operators that take the same data type on both sides.
However, sometimes it is possible to design compatible hash functions
for two or more datatypes; that is, functions that will generate the
same hash codes for <quote>equal</> values, even though the values
have different representations. For example, it's fairly simple
to arrange this property when hashing integers of different widths.
</para>
<para>
...
...
@@ -346,9 +352,9 @@ table1.column1 OP table2.column2
the operator, since of course the referencing operator family couldn't
exist yet. But attempts to use the operator in hash joins will fail
at run time if no such operator family exists. The system needs the
operator family to find the data-type-specific hash function for the
operator's input data type
. Of course, you must also create a
suitable
hash function before you can create the operator family.
operator family to find the data-type-specific hash function
(s)
for the
operator's input data type
(s). Of course, you must also create
suitable
hash function
s
before you can create the operator family.
</para>
<para>
...
...
@@ -366,6 +372,17 @@ table1.column1 OP table2.column2
to ensure it generates the same hash value as positive zero.
</para>
<para>
A hash-joinable operator must have a commutator (itself if the two
operand data types are the same, or a related equality operator
if they are different) that appears in the same operator family.
If this is not the case, planner errors might occur when the operator
is used. Also, it is a good idea (but not strictly required) for
a hash operator family that supports multiple datatypes to provide
equality operators for every combination of the datatypes; this
allows better optimization.
</para>
<note>
<para>
The function underlying a hash-joinable operator must be marked
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录